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Foreword 



Early in its history as a corporate entity, 
Informatics Inc. sponsored a symposium on 
disc files. The response to that symposium 
was beyond all expectations. More applicants 
were turned away than were able to register. 

Experience with that disc file symposium 
showed that much management time and effort 
must be devoted to the staging and program- 
ming of a successful presentation. Therefore, 
Informatics Inc. proposed to Engineering 
Extension of the University of California, Los 
Angeles, joint work on an On-Line Computing 
Systems Symposium to be held early in 1965. 
Acceptance of this proposal by UCLA meant 
that the full facilities, prestige, and know-how 
of a great university could be brought to work 
on this symposium. The results have fully 
vindicated the wisdom of this decision. 

The final registration of 768 shows the great 
current interest in on-line systems. This reg- 
istration also exceeded all estimates. 

The cooperation of Informatics Inc. with its 
heavy, first-hand skill and interest in pro- 
gramming and specifying on-line systems, and 
the University of California, devoted through 
such organizations as Engineering Extension 
to bringing new and current fields of knowl- 
edge to people, provided an outstanding exam- 
ple of the benefits to be gained by education 
and industry working together. 

Jackson W. Granholm 
Sherman Oaks, California 
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Preface 



On-line data processing systems have re- 
cently become of interest in digital computer 
applications. Developments in digital trans- 
mission and availability of faster bulk storage 
devices and the use of man/machine interface 
devices have stimulated a new kind of data 
processing. In this processing, information is 
entered into the system as it is generated. 
Outputs are requested as they are required. 
These inputs and outputs are occasioned by 
external stimuli— man or machine— to which 
the computer responds. 

On-line computing systems include at least 
two important classes of systems. The first is 
one in which response times are measured in 
milliseconds. Such systems are automatic, and 
many of them are closed loop, since the tim- 
ing requirements preclude the intervention of 
men. Examples are process control applica- 
tions, military satellite control systems, and 
radar tracking and recording systems. 

The second important class includes com- 
puter systems to which several interrogation 
and display devices are connected, thus es- 
tablishing man/machine communication. 
Examples are found in military command and 
control systems, space vehicle command and 
control systems, and various commercial sys- 
tems. 

The three-day symposium at the University 
of California Extension, Los Angeles, spon- 
sored by the Department of Engineering and 
Informatics Inc. included discussion of both 
classes of on-line systems. In addition, it cov- 
ered, with a considerable degree of thorough- 
ness, the principles, disciplines, and practices 
which are applicable to on-line systems design, 
both in machinery and programming. 

The symposium was divided into six morn- 
ing and afternoon sessions each with a sep- 
arate chairman. These sessions and their 
chairmen were: 

Session I: Motivations 

Chairman— Dr. Gerald Estrin, Professor of 
Engineering, UCLA 
Session II: Techniques 

Chairman— Francis V. Wagner, Vice Presi- 
dent, Plans and Programs, In- 
formatics Inc. 



Session III: Approaches 

Chairman— Dr. Michel A. Melkanoff, Asso- 
ciate Professor of Engineering, 
UCLA 
Session IV: Methods 

Chairman— Jackson W. Granholm, Vice 
President, Technical Communi- 
cations, Informatics Inc. 
Session V: Applications 

Chairman— Dr. Bertram Bussell, Assistant 
Professor of Engineering, UCLA 
Session VI: Examples and Summary 

Chairman— Irving Cohen, Vice President, 
Command and Control, Infor- 
matics Inc. 

The proceedings are organized in parts to 
correspond with the sessions. 

The Welcome Address was given by Dr. 
Paul H. Sheats, Dean, University of Califor- 
nia Extension. The Banquet Address was by 
Dr. Simon Ramo, Vice Chairman of the 
Board, Thompson Ramo Wooldridge Inc., and 
President, Bunker-Ramo Corporation. Dr. 
Walter F. Bauer, President, Informatics Inc., 
was Chairman of the Banquet, and Jackson W. 
Granholm, Vice President, Technical Commu- 
nications, Informatics Inc., was Toastmaster. 

The papers for the symposium were se- 
lected by an advisory board consisting of: 

Dr. G. Estrin, Dr. C. B. Tompkins and Dr. 
S. Houston, of UCLA, and Dr. W. F. Bauer, 
F. V. Wagner, and J. W. Granholm, of Infor- 
matics Inc. 

Secretarial assistance was given by Mrs. 
Betty Leventhal of UCLA and Mrs Rose 
Marie Gonzales of Informatics Inc. Public Re- 
lations were handled by Tom Kramer of 
UCLA, and Frank Crane and Robert Stone 
of Informatics Inc. 

The assistance of many other people at 
UCLA and Informatics Inc. who helped to 
make the symposium possible is also grate- 
fully acknowledged. 

Eric Burgess 
Editor, 
Informatics Inc. 
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The Future of On- Line Systems 



THE SYSTEMS 

There are six kinds of on-line systems : 

1. Systems for Processing Control let fac- 
tories manufacture products more cheaply. 
Process control systems do everything from 
simple feedback control to optimizing profits 
through linear programming. These process 
control systems have, and will have, a big 
effect on our domestic production capability. 

2. Inquiry Systems permit people at many dif- 
ferent locations to find out what is going on. 
Most familiar is the airline reservations sys- 
tem, but more such systems will come into use 
in the years ahead. 

3. Specialized On-Line Systems perform par- 
ticular complicated tasks ; often military tasks. 
Industry is only just beginning to make use of 
specialized on-line systems for engineering 
and design. 

4. On-Line Programming Systems put the raw 
power of a computer at the immediate disposal 
of a human user. Evidence of today's great 
interest in on-line programming systems is 
that more and more of them are being used. 

5. On-Line Problem-Solving Systems will be 
required for doing even the simplest tasks 
without human help. Such systems will require 
the techniques for pattern recognition, process 
control, and heuristic programming, and will 
unite them meaningfully. It will be so difficult 
to do even the simplest tasks automatically 
that we will be busy with these tasks for some 
time to come. 

6. On-Line Instrumentation will bring us 
better understanding of the interplay of the 
programs and data within the computer. Sim- 
ple devices and programs to keep track, 
on-line, of what the computer does will bring 
us better understanding of what our informa- 
tion reprocessing systems are actually doing. 



THE FUTURE 

I will try to divide the future into two 
categories : the immediate future and the dis- 
tant future. 

During the immediate future, we can expect 
systems to come to fruition which we now 
know how to design and how to build. In talk- 
ing about systems for the immediate future, 
we talk about systems which have some recog- 
nizable place in the current scheme of society. 
In the immediate future, there probably will 
not be any tremendous political upheaval or 
war, or natural catastrophe which would cause 
the entire technology of the world to take a 
new turn and, thus, render my predictions 
ridiculous. 

But, the future is long— probably longer than 
the past. Information processing is something 
we have proved can be done, and we are going 
to do more of it. I believe that, in principle, it 
is possible to make information processing 
systems which will do intellectual tasks that 
human beings cannot possibly hope to do. The 
creation of such systems is a challenge that 
society will accept. The only question is when ? 
About when we can only speculate, because the 
future of any technology is so interwoven with 
the political, social, and scientific develop- 
ments around it. 

SYSTEMS OF THE FUTURE 

1. Process Control Systems— There is no reason 
why Man should have to work for a living. 
Everyone recognizes the trend toward more 
and more leisure time— time in which our 
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activities are not prescribed. Leisure time is 
not necessarily idle time; if we do nothing 
during leisure time the world will continue 
as before. In the foreseeable future, process 
control and automation will make possible 
more leisure time for all of us. 

One of the major social issues yet to be 
faced is how to measure an individual's con- 
tribution in a leisure society. Today, we pay 
people for working, or for concentrating on 
a single assembly operation for a long and 
unpleasant period, or for being away from 
home, or for taking personal risk, or for art- 
istry—for making or doing something "beauti- 
ful", or for inventiveness— for devising some- 
thing which makes life more pleasant for 
other people. Or, we pay people for responsi- 
bility—for making decisions which will have 
to stand the test of history and expose the 
decider to historical recognition or historical 
contempt. In a leisure society, what would 
people be paid for? How would you recognize 
a person's contribution to society? If no one 
works, except when he wants to, or no one 
spends long onerous hours at menial labor, 
except if he wants to, how do we recognize 
a man's contribution to society? The long term 
future of on-line systems for process control 
and automation rests in our ability to answer 
these questions. 

2. Inquiry Systems— Today, you can find out 
from anywhere in the country what space is 
available on any airplane, almost instantly. 
But that is only the beginning. In the fore- 
seeable future, we could automate all sorts of 
information retrieval, from isolated inven- 
tories to the entire content of the Library of 
Congress. 

An important part of an information re- 
trieval system is its completeness. If I could 
reach 75 per cent of the technical literature 
and 99 per cent of the technical experts in a 
field through a certain information retrieval 
system, I would not need to keep a personal 
library. Finding out what had been done in 
a certain field would be a simple one-inquiry 
task. Just as the utility of the telephone 
system is that everyone has a telephone, so 
the full potentiality of an information re- 
trieval system will come only when it contains 
all pertinent information and almost everyone 
interested uses it. 

Today, our inquiry systems are systems of 
which we ask questions, and not systems 
which can phrase and ask questions of human 



beings. On-lineness is a two-way street, and 
our success in using it comes from our will- 
ingness to make systems which can ask us 
questions as well as give replies to questions 
asked. Think of Socrates teaching by merely 
asking questions! 

Automated libraries will be most useful 
when they "understand" the information 
stored in them. Suppose you wanted to find 
out some fairly obscure technical fact. You 
could go to the library and ask the sweet 
young librarian a technical question. The 
librarian may know all about the books in 
the library and where they are stored, and 
what the numbering systems mean, and the 
procedures for signing them out, but she has 
not the foggiest notion of the content of all 
these books— and certainly not of the book 
which will contain the information you want. 

But imagine asking a technical colleague 
the same question. Your colleague has at his 
command the content of the book which con- 
tains the facts you need. He knows nothing 
about libraries, or numbering systems, or 
information retrieval, or cataloging methods, 
but he does know the facts that you want. 
Inquiry systems, in the future, will become 
more and more able to understand and cor- 
relate the facts. 

Imagine, if you will, in the far, far, distant 
future a computer which contains in its files 
all that has ever been written. In its spare 
time, this computer mulls over these facts to 
understand the implications of them and to 
try to come to new conclusions. This computer 
knows, of course, the interests of all the 
people it serves, because it has records of all 
the questions they have ever asked it. Given 
a new question, this machine of the future 
can not only regurgitate the information 
which it contains but also can put the asker 
in communication with other people interested 
in that subject. 

3. Elaborate Special Purpose On-Line Systems 

have been devised primarily for military pur- 
poses. In the immediate future, we can expect 
industry to start using specialized on-line sys- 
tems for design and management. There are 
obvious benefits to automatically performing 
mathematical computations which quickly and 
accurately predict the strength and weakness 
of designs and plans. There are bigger ben- 
efits to using on-line systems as a communica- 
tions medium between people. 
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When one person designs or plans some- 
thing, he has no communication problem with 
himself. He can write cryptic notes on pieces 
of paper and leave them scattered around his 
desk in a positional notation which only he 
need understand. He can look in the upper- 
right corner of his desk for that memo on 
what he did yesterday. His individual work 
will proceed at a certain pace. 

When more than one person gets in the 
act, however, a communication problem is 
created. If a design job is divided up between 
people, the separate parts have to mesh cor- 
rectly. If it is possible for the separate actions 
of individuals to drastically affect the actions 
of other individuals, then an almost hope- 
lessly confusing tangle is possible. Imagine 
us designing an aircraft. My responsibility is 
the electrical wiring; yours is the gas tanks. 
If either of us changes his mind about the 
position of our part of the design, the other 
must be informed as quickly and easily as 
possible. By merely providing up-to-date de- 
sign information to each user, an on-line 
design system could be a big help. 

We have only just begun to work with 
computers as communication media between 
people. Today, by linking remote stations, we 
can allow one person to "look over the shoul- 
der" of another through a computer. We have 
yet to combine the functions of the design 
system and the inquiry system. The ability of 
many people in widely separated locations to 
know exactly what is going on has already 
proved practical in the airline reservation 
system. It must be included in our computer- 
assisted design systems. 

4. Programming Systems— The biggest interest 
in on-line systems, judged at least by the 
noise people are making today, is in on-line 
programming systems. In the past two years, 
we have learned a great deal about how to 
get on-line service for computer users. We 
have a spectrum of on-line programming sys- 
tems, from simple and fast to complex but 
slower. But we are only just learning how 
to time share our computers. There is a great 
deal still to be learned about memory sharing 
and routine sharing. Such techniques will 
enable more than one user to share the capac- 
ity as well as the time of the computer. 

Today's on-line debugging techniques are 
still rather crude. We can now communicate 
with a computer program in symbolic assem- 
bly language if we used such a simple language 



in writing the program in the first place. It 
is possible to insert break-points in the pro- 
gram, to stop it when certain conditions arise, 
and then to examine what went wrong. We 
have not yet learned to communicate with 
similar fluency in any higher-level language. 
We have not yet built the systems— although 
we could within the next year— which would 
let us have the same fluency of on-line com- 
munication with programs written in higher- 
level languages. 

At the moment, we are still adapting off- 
line techniques to our on-line systems. For 
instance, we still see remnants of the card 
image in on-line systems. If, in a truly on-line 
system, there is no need for punched cards, 
why maintain the card image? Of course, we 
maintain the card image because it is more 
economical to adapt our existing card-oriented 
programming systems to our new on-line tech- 
niques than to start afresh. Our progress in 
getting "on-line" can be measured by our suc- 
cess in abandoning entirely old concepts which 
do not contribute to an on-line system. 

We are only just beginning to explore sys- 
tems where the computer asks questions of 
the programmer to resolve ambiguities in 
what it is told. Imagine a situation five years 
from now when, given a problem to solve, I 
approach a machine and say, "I have a prob- 
lem in numerical analysis to solve." The ma- 
chine asks me a few questions about my prob- 
lem and decides what the appropriate pro- 
gramming language is to use. I write a few 
expressions in the language, making, as usual, 
a few mistakes. The machine asks, in each 
case, what I really meant— perhaps giving me 
an interpretation of what I said in different 
terms. I recognize my mistakes and correct 
them immediately. 

What languages are appropriate to on-line 
use of a computer? McCarthy claims that pro- 
gramming a computer in English is like flying 
an airplane with reins and spurs. But, pro- 
gramming a computer in English is a much 
more reasonable proposition for me than pro- 
gramming it in Hindustani; just as flying 
an airplane with my hands and feet is a much 
more reasonable proposition for me than fly- 
ing it with my elbows and knees, because using 
my hands and feet seems more "natural". To 
improve all our on-line systems, we need more 
and better languages of communication be- 
tween the man and the machine which are 
"natural" in the sense that they are easy to 
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use and fit the task. Why can't I write math- 
ematical equations which look like mathemati- 
cal equations and have the machine accept, 
compile and perform them? Why can't I de- 
scribe network problems to the computer by 
means of the picture showing the network? 
Why can't I, in filter design, place poles and 
zeros on the complex plane? The answer in 
each case is: I can in principle, but not in 
practice. As yet, the techniques which let me 
do these things are not widely used. The pros- 
pect of the next five years is exciting because 
there is so much that we now know can be 
done, so much that we even know how to do, 
so much that we can put into use by just 
taking the time and trouble to do so. The 
prospect of the next five years is exciting 
because we will be finding out which of the 
things that we know how to do are actually 
worth using, which are economically feasible, 
and which are truly useful. 
5. On-Line Problem-Solving Systems— The time 
is ripe to collect the techniques of pattern rec- 
ognition, process control, and heuristic pro- 
gramming together to gain a new capability. 
There are simple tasks to be done in places 
such as space where humans cannot go, or 
even communicate, which machines based on 
these three techniques could do automatically. 
In the near future, we can expect such ma- 
chines— "automata" if you will-to come into 
experimental use. 

The development of automata will be good 
for the contributing disciplines. Pattern rec- 
ognition workers have taken little account of 
systems which, by acting, can gather addi- 
tional information to clarify ambiguous pat- 
terns. Have you ever had to move your head 
to complete your inspection of something? Of 
course you have. Similarly, we must learn 
how to make computers actively seek infor- 
mation about their environments. In the con- 
text of visual pattern recognition, this implies 
"taking a better look." In the context of man- 
machine interaction, this implies that the 
machine might pose a question to the man. 

Process control today is little removed from 
the servomechanism. While it is true that we 
control very complex processes, the rules used 
are relatively simple. We think naturally of 
assembly line balancing, to optimize profit. 
The processes controlled today are uniform, 
In fact, industries which deal in non-uniform 
products have had some difficulty in automat- 
ing. For instance, an automated coal mining 



scheme failed because of the variation in the 
size of the coal seam. Automated shoemaking 
is made difficult because of the variability of 
leather. Pattern recognition and heuristic pro- 
gramming can contribute versatility to process 
control. Opening up this new area for appli- 
cation of heuristics will stimulate our heur- 
istic techniques. 

6. Instrumentation— On-lineness is a two-way 
street. Not only can we put computers on-line 
with human beings, but also we can put human 
beings on-line with computers. We can devise 
and build instrumentation to let a human see 
what is going on inside the computer. The in- 
formation processing industry is uniquely 
wanting in good instrumentation ; every other 
industry has meters, gauges, magnifiers— in- 
struments to measure and record the perform- 
ance of the machines appropriate to that 
industry. Think of a gasoline engine under 
test. The test stand bristles with devices to 
measure temperature, speed, vibration, fuel 
consumption, and so-on. Civil engineers have 
even instrumented a huge block of concrete, 
a dam. Gauges embedded in the concrete meas- 
ure strain, temperature and humidity deep 
within the structure. How else could you find 
out what the internal conditions of the struc- 
ture are? 

Now think of a computer program under 
test. We run several sample problems, and 
check the answers. We rarely bother even to 
measure the time it takes to run the program. 
Certainly, we do not bother to take statistics 
on the number of times the various program 
paths are taken. Yet, in the information pro - 
cessing industry we are uniquely able to make 
instruments out of the very same stuff, com- 
puter programs, out of which the device being 
tested is made. 

Some simple computer program instru- 
ments have been made. I have used a program 
which interprets the program under test and 
makes a plot of the memory address of the 
instruction being executed versus time. 1 * Such 
a plot shows the time the program spends 
doing its various jobs. In one case, it showed 
me an error which caused a loss of time in a 
program which nonetheless gave correct an- 
swers. At Stanford University, a program 
which plots the depth of a problem tree versus 
time was used to trace the operation of a 
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Kalah-playing program. Kinslow printed out 
a picture of which parts of memory were "oc- 
cupied" as a function of time for his time- 
sharing system 2 . The result shows clearly the 
small spaces which develop in memory and 
must remain unused because no program is 
short enough to fit into them. Project MAC 
is using a display to show the dynamic activity 
of jobs within its scheduling algorithm. 
Watching this display, one can see jobs mov- 
ing to higher and lower priority queues as 
time passes. 

Such instrumentation is not in widespread 
use. We can and will develop instrumentation 
which will be automatically inserted at com- 
pile time. A user easily will be able to get a 
plot of the various running times of his pro- 
gram. Think of the thousands of dollars saved 
by tightening up that one most-used program 
loop. Instrumentation can identify which loop 
is the most used. 

CONCLUSIONS 

The future of on-line systems depends a 
great deal upon the future of off-line systems. 
There is a lot of talk these days about a semi- 
automated mathematical laboratory in which 
a mathematician could prove theorems that he 
could not prove without computer assistance. 
How about having the computer prove the 
theorems all by itself? Suppose the artificial 
intelligence people make a machine which can, 
in fact, prove new theorems all by itself. What 
then becomes of our semi-automated math- 
ematical laboratory? It's useless. Suppose we 
finally write a computer program which is able 
to write computer programs. Suppose we could 
state our problems to a computer able to pro- 
gram itself to solve the problems. What then 
will become of the on-line programming sys- 
tem? It will be unnecessary. 

Today, we are in a very exciting period 
when interest in on-line systems is very high. 
Our great surge of interest in on-line systems 
cannot last forever. What is next? What comes 
after the on-line systems? Perhaps we shall 
return to off-line systems as our capability 
grows to have machines become better able 
to do things all by themselves. Probably it 
takes a very large computer to solve useful 
mathematical theorems automatically. But, it 
is nonetheless likely that we shall eventually 
build such a system. In the past, there have 
been cycles in our interest in on-line systems. 
In the early days, on-line use of computers 



was common because no one knew anything 
else to do. Then there were the bleak years 
of insulation between users and computers to 
gain computing "efficiency." Now, we are 
again in an outburst of interest in on-line 
computer systems. 

In the future, also, there will be changes 
in the emphasis on on-line systems. In five 
years, on-line programming systems will be 
commonplace, and a conference on on-line 
systems would be out of place. Research inter- 
est in on-line systems will have faded, although 
application of them will still be widespread. 
Perhaps general-purpose automatic problem- 
solvers will come into use soon after that. If 
so, even the use of on-line programming sys- 
tems may decrease. 

Eventually, the process control on-line stud- 
ies and the automatic problem-solving work 
will come together to make automata. Com- 
puters will then be truly on-line with the 
physical world in the same sense that we 
human beings are on-line with the physical 
world. Once again, there will be a resurgence 
of interest in on-line systems. What I am 
predicting is that today's interest in systems 
in which a man and a machine get together 
on-line will be replaced in the distant future 
by interest in systems in which a computer 
gets directly on-line with the real world, sens- 
ing and interacting with it directly through 
transducers. The "real world" with which 
such systems interact will include human 
beings, of course. 

CHARGE 

We are embarked on the greatest adventure 
of all time. We believe that human beings are 
individually valuable and have inalienable 
rights. We believe that human beings are not 
to be used as slaves. We must find something 
else to give us the freedom of action which we 
call leisure. We turn, of course, to the ma- 
chine. It will do our work for us so that we 
may be free to do only things which we 
wish to do. We will be free to exercise our 
creative impulses. 
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On-Line Systems— Their Characteristics 

and Motivations 



INTRODUCTION 

The current consensus among computer 
professionals is that on-line applications rep- 
resent the wave of the future. The existence 
of this symposium itself stems from that 
conviction. However, as with all new subjects, 
some important basic questions arise. It is well 
to contemplate what on-line computing is and 
why it is becoming so important. 

First, some estimates and forecasts (Figure 
1): on-line computing probably represents 1 
per cent of the total computer activity in the 
country today. It will probably represent 50 
per cent in five years. Within ten years it will 
probably represent nearly all computer activ- 
ity. This symposium and our discussions come, 
then, just at the beginning of this new "rev- 
olution". 

Modern computers are about fifteen years 
of age. The computer profession has under- 
gone much strife during its formative years 
but now has reached some degree of structure, 
standardization and predictable growth pat- 
tern. Everyone in the computer world knows 
what subroutines, assemblers and simulation 
programs are. There is even a rather universal 
acceptance of the difference between an assem- 
bler and a compiler. However, just as this 
status is being reached, interest has rapidly 
developed in drastically new approaches to 
computer use. We are now confronted with 
new words and techniques : time-sharing, real- 
time, on-line, and multi-programming. In view 
of this, it seems appropriate not only to define 
these terms, but also to discuss the total struc- 
ture of on-line computing in an attempt to 
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interrelate the various aspects of this new 
era. This is the major objective of this paper. 

Another objective is to examine the motives 
of those advocates of on-line computer use. 
Is such use cheaper? What does it gain for 
the user? What is to be gained by on-line 
computing versus batch processing? 

But the prime question may well be whether 
on-line computing itself is basically new, or 
does it represent a natural extension of older 
techniques ? It is interesting and instructive to 
trace the evolutionary paths which brought us 
to our present capability (or desire for capa- 
bility) of on-line computing. 

Last, but not least, is the series of interest- 
ing questions dealing with techniques and 
technologies which inspired or were made nec- 
essary by on-line computing. The implications 
to the user, the programmer and the machine 
designer are profound, but not unattainable. 
They should be spotlighted early to allow time 
for balanced development of all their facets. 

DEFINITIONS AND STRUCTURE 

First, it is the proper time for the comput- 
ing field to rid itself of old fashioned words 
and adopt more meaningful terms. The phrase 
"real-time" is itself a meaningless expression. 
This hyphenated expression was important a 
decade ago when a computer was lashed to 
instrumentation or tied closely to the outside 
world. The term was used to describe those 
tasks that needed to be locked or synchronized 
on a second or millisecond basis to some real 
time occurrence. As applications of this type 
branched out, the term became more and more 
inappropriate. Question: is the SABRE sys- 
tem for airline reservations appropriately 
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called a "real-time" system? The fact that 
lengthy papers 1 * have been written attempt- 
ing to define real time is, in itself, ample evi- 
dence that this misnomer for an application 
category and its description should be 
straightforward and simple. 

The word on-line has been chosen as the 
title for this symposium. It is more meaning- 
ful than "real-time". It seems that definitions 
are long lasting and meaningful only if they 
are simple. With this in your minds, the fol- 
lowing definition of on-line computing is put 
forth for your consideration. 

"On-line computing is the efficient 
use of a computer in a system in 
which the computer interfaces with 
man or other machines to which it 
reacts in receiving and supplying 
information." 
Let us not attempt to define on-line or real- 
time by some abstract reference to the passage 
of time or the urgency of the receipt of data, 
but rather, let us define it in terms of the 
environment of the computer system itself 
and the manner in which it is used. 

The above definition should withstand your 
scrutiny. 



* Numbers refer to references at the end of the paper. 



Analog/digital hybrid systems are on-line 
computing systems since the analog computer 
itself is a clever machine which, like man, 
receives and supplies information. 

An airline reservation system is on-line 
since the computer reacts to signals generated 
at the ticket office via an input device. 

Systems oriented towards scientific problem 
solving by use of a console are again on-line, 
since the console itself is the interface which, 
in turn, receives information from, and gives 
information to, the human who has a need 
to know. 

The purist may argue that on-line comput- 
ing then refers to all computer systems, since 
they must all have devices such as card read- 
ers and punches to give and receive informa- 
tion. We can avoid this weakness in the defi- 
nition by insisting that interfaces with men 
and machines do not include conventional 
input/output equipment. We can also insist 
that the words "to which it reacts" rule out 
conventional input/output since, in those 
cases, the computer itself controls or drives 
the input or output process instead of reacting 
to it. In other words, for on-line systems, the 
computer is embedded in a system, and the 
part of the system outside the computer syn- 
chronizes the system. The signals to which 
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the computer reacts are frequently random. 
This is in contra-distinction to those applica- 
tions where the computer itself synchronizes 
input/output equipments. 

Referring to Figure 2, it seems natural to 
divide on-line computing into two major areas : 
man/machine oriented applications, and in- 
strumentation-oriented applications. In the in- 
strumentation-oriented case, the computer is 
locked into instrumentation to which it reacts ; 
in this case human participation is incidental. 
On the other hand, in the man/machine ori- 
ented case, instrumentation primarily enables 
man to "talk" to the system. The system is 
necessarily oriented to the console and to the 
men who operate it. 

We should hasten to add at this point that 
in creating definitions and meaningful struc- 
tures, the obvious weakness is that many sys- 
tems are not pure but, in fact, blended. In 
reality, larger systems are both instrumenta- 
tion-oriented and man/machine-oriented. A 
large scale communication system, for ex- 
ample, will probably have an elaborate man/ 
machine subsystem which allows extensive 
monitoring of message processing, or for 
human intervention for pathological cases 
which might arise. 



Instrumentation structured systems might 
further be broken down into "simulation" and 
"discrete" types. A simulation type is one 
which is closely synchronized by, or in concert 
with, events as they are happening. Now with 
the discrete type, the system reacts to signals 
which are less frequent and are mostly ran- 
dom, such as those described by Poisson dis- 
tributions. The latter are systems in which 
queues form and service may be relatively un- 
predictable, and may vary considerably rela- 
tive to demand. 

But we are here to examine' the man/ma- 
chine systems. Therefore, let us look with 
greater precision to applications and systems 
where the man is closely interacting and 
reacting with the system. 

Referring again to Figure 2, there seem to 
be three major areas for man/machine appli- 
cations; these are problem solving, program- 
ming and computer use. In problem solving, 
man wants to have the computer carry out 
complex processes whose parts are chosen 
and initiated by him. The computer is solving 
the problem in the sense of carrying out the 
detailed manipulations required. The man acts 
more as a control system monitor ; he controls 
the pieces of computation. One of the best 
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examples in problem solving applications is 
that developed by Culler and Fried 2 . In their 
application, the computer can perform a wide 
variety of mathematical operations on a col- 
lection of points on an interval. 

On-line programming is the second area 
identified. In this application, the man uses 
the computer to develop an end product; an 
object program which accomplishes a pre- 
scribed known processing result. The pro- 
grammer has used the computer to assist him 
in the process of selecting subroutines, pre- 
paring programming pieces for proper em- 
bedding into larger systems, for supplying 
data, for correcting the format of his instruc- 
tions, or for examining the logic of his pro- 
gram structure. There seems to be little of 
this being done now as I have defined the 
problem here. Most on-line programming sys- 
tems involve simulation of problem-oriented 
language statements which comes under the 
heading of "computer use", as described in 
the following paragraph. 

The third area of on-line applications is 
heavily oriented toward man. This refers 
simply to the use of the computer by the man. 
In this application the computer can be con- 
sidered as his strong right arm. The problem 
is solved by the man assisted by the machine. 
In input and output of data, for example, the 
computer is assisting the man in establishing 
formats, priorities, data locations, and so on. 
Another application is the question of a data 
base where the man is asking questions, and 
succeeding questions depend on previous an- 
swers. Still another application in this cat- 
egory, is the control and monitoring of large 
scale systems. 

While we are in the business of defining and 
naming processes, there is another term which 
needs attention. We have already dissected 
"real-time" and have concluded that it is an 
old-fashioned phrase which has little meaning 
in a modern sense. Another unfortunate 
phrase is "time-sharing". This phrase is usu- 
ally used to describe the simultaneous use 
of a machine by a number of programmers or 
analysts. Many descriptions appear in the lit- 
erature 3 ' 4 - 5 ' 6 . However, in these systems it is 
not the sharing of the machine which is the 
most important. Rather, it is the orientation 
of the machine to the human. To be specific, 
time sharing comes into the picture because 
this is the only current efficient way of using 
a computer in close cooperation with a human, 



since the machine would not be used efficiently 
during the "head scratching" period of the 
operator, and in a "time shared" system, many 
operators can use it simultaneously. Thus idle 
time is reduced. Time sharing is a result of 
the fact that there is the man/machine orien- 
tation. To illustrate, the most important thing 
about an automobile is that it supplies trans- 
portation. The fact that it is efficient to have 
round wheels and a gasoline engine is over- 
whelmed by the transportation factor. And so 
with computers. Thus, the expression "time 
sharing" puts the emphasis on a secondary 
characteristic and is, therefore, not good ter- 
minology. I offer that "on-line" is a much more 
accurate and representative name. 

MOTIVATIONS FOR ON-LINE SYSTEMS 

In general, the motivation for on-line sys- 
tems is to make the computer a more powerful 
tool. The computer is being made into a more 
powerful tool by building it more responsive 
to the user— more responsive especially in re- 
spect to type of information obtained, and 
time required to get it. 

These systems greatly increase the efficiency 
of the user by giving him information which 
reduces red tape and mundane clerical opera- 
tions. They bring the user closer to the data 
inside the computer and make it more acces- 
sible to him. They give the user only the infor- 
mation he needs, when he needs it. In other 
words, with on-line systems there are no 
lengthy outputs from which the operator must 
laboriously select the desired information. The 
on-line concept is the skeleton key to the files. 

However, it behooves us to look carefully at 
on-line systems from the standpoint of the 
areas of assistance which the computer can 
provide to the user. If this is not done, the 
danger exists that we would expect too much 
from on-line systems; in our enthusiasm for 
all their merits we could create a considerable 
disenchantment among over-sold users. 

In the situation of man interacting and re- 
acting with the cool gray computer, the appro- 
priate question is, "How can the computer 
help the man?" The following four state- 
ments about this assistance should represent 
a mutually-exclusive and mutually-exhaustive 
set of assistance areas. They are: 

1 . Correct an input. 

2. Accept a query or the specification of an 
operation, then perform the required de- 
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sired operation which should provide the 
proper information to the user necessary 
to accomplish the next step. 

3. Accept and appropriately handle informa- 
tion to enable the computer to interpret 
correctly future information which it may 
receive from the user, or 

4. Direct, on a step-by-step basis, a procedure 
for information input and output. 

Let us examine briefly each of these areas. 

To correct an input and to immediately sig- 
nal the man in the loop for a correction or the 
need for a correction, is an important time 
saving factor. Many needless hours of "turn 
around time" can be saved by finding out im- 
mediately that a transcription error exists. 
This is just one example. 

One of the important aspects of computer 
use is in the area of computer aided processes. 
The man is carrying out a number of logical 
steps and needs the extra strength of the com- 
puter to help him in each of these steps. Be- 
cause the specification for each step depends 
upon the results of the previous step, there is 
need for fast response. Consider, for example, 
a military commander asking questions about 
the status of enemy forces. It should be easy 
for you to imagine the series of interrelated 
interrogations. 

While carrying out the procedures in many 
on-line systems, it frequently becomes obvious 
that certain procedures should be changed. For 
on-line problem solving, for example, if it is 
found in solving certain problems or in solv- 
ing certain levels of problems that a pro- 
cedure, (e.g., multiply by cos X and integrate 
over range to 1 ) occurs frequently, it can be 
specified as a standard instruction, and the 
computer will react appropriately each time 
this instruction is received. 

Computer-directed procedures are an im- 
portant aspect of on-line computing and are 
little understood or appreciated. For example, 
they allow a complex query to be asked of a 
machine under the control of another machine 
and with the assistance of a third machine. 

One thing should be borne in mind always 
about on-line systems. They increase the bur- 
den on the computer so that the efficiency of 
the man can be increased. We must realize 
always that a penalty or a price is extracted 
for each increment of increased human effi- 
ciency; more computer time, more complex 
computers, greater input/output equipment, 



and increased console costs. The tradeoffs 
undoubtedly favor ever increasing on-line 
capability. However, no system design should 
occur without recognition of the prices de- 
manded. 

COMPUTER-LEAD PROCEDURES 

The importance of this area and its appar- 
ent lack of appreciation by computer users 
suggests more attention should be given to 
the definition and the benefits which can be 
derived. 

Consider for example, the process of com- 
plex interrogation of a large data base. The 
computer must be an active participant in the 
process or the operation becomes unwieldy. 
Consider the functions as shown in the center 
panel of Figure 3. The user must perform the 
selection, but functions must be performed re- 
lating to the logic or syntax of the request and 
to the consultation of a dictionary or format 
specifications. These in turn require a look-up 
operation to files which provide the required 
data. In manual operation, as shown, the com- 
puter performs only the process of retrieval 
and presentation. Obtaining the procedure to 
be followed by consulting a comprehensive 
operator's handbook is left as a burdensome 
human-only operation. 

In the console-computer automated oper- 
ation the only function left to the operator is 
that which must be left to him ; the selection. 
The computer leads him by the hand, hope- 
fully by the proper digits, down the rocky 
procedural path. 

As a simple example of the principle es- 
poused, imagine that a military commander 
wishes to have information about POL (petro- 
leum, oil, and lubrication) resources and 
airfields in a certain section of the country. 
Also, suppose he wishes to have a list of air- 
fields in five western states which have a POL 
availability of 80 percent after an enemy at- 
tack. It is totally unacceptable and time con- 
suming for him to make the request to a 
technician who would then transfer the infor- 
mation to an obscure code or punch it on a 
card. Rather, he makes the request to a staff 
officer who directly questions the machine. 

Consider the following as a sample pro- 
cedure. The staff officer may specify to the 
machine that he is interested in "installa- 
tions" and chooses, from a list of installations 
which the machine gives him, the category 
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"airfields". He then tells the machine he is 
interested in "resources" and the machine 
provides him with a list of resources from 
which to choose. A similar procedure takes 
place with respect to the geographic location. 
When he tells the machine that he is inter- 
ested in an availability of 80 percent, the 
machine responds with a form to fill out. The 
officer enters the number 80 on the form and 
the list is printed out. 

The format of the request is natural. It is 
neither highly stylized, nor codified. The staff 
officer making the request and pushing the 
buttons is himself a military man who under- 
stands the commander's request and the 
reasons for it rather than the technical details 
of how to make the machine accept or respond 
to the request in its complex electronic way. 



The benefits of computer-lead procedures, 
however, are not limited to interrogations of 
the data base. The inverse procedure benefits 
equally man and machine. Consider the input 
of data which is relatively unstructured. The 
computer, of course, must finally accept and 
file the information in a highly structured 
form so that it may be retrieved efficiently. 
The computer can direct a procedure which 
allows the human to input the data in the 
order and in the form which the machine can 
accept. 

THE EVOLUTION OF ON-LINE SYSTEMS 

The advent of on-line computing systems 
has not blossomed suddenly, nor has it sprung 
full grown as a technical revolution. Rather, 
it can be viewed as a normally evolving ca- 
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pability. The capability and potential has been 
there and recognized for some time; it is the 
increased attention being given the techniques 
which is sudden and dramatic. 

To illustrate the evolutionary process, con- 
sider Figure 4. Portrayed there is capability, 
increasing from top to bottom accompanied by 
passage of time. In computer use in the early 
'50s it was the conventional input/output, the 
operator console and the utility and assembly 
programs. People who used computers and sat 
at consoles for long hours could not help but 
conclude that there was a faster, better way 
to give and receive information from an oper- 



ating computer. The SAGE system 7 and the 
early output device using a cathode ray tube 
were examples. Also, operator console pro- 
cedures became more sophisticated. Many sys- 
tem designers concluded that if you could 
give information at the console for diagnos- 
ing hardware failures as the maintenance 
men did, then why could not the user give 
complex instructions to the machine dealing 
with the processes and procedures being car- 
ried out by the machine? These were illus- 
trated in a number of systems which have 
been described in literature 8 . At the same 
time, strides were being made in non on-line 
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areas with the development of new, advanced 
compiler and assembly systems in step with 
powerful computer-user languages. 

System designers, naturally, borrowed heav- 
ily from the techniques being developed in 
stylized console and monitor system operation 
to develop console-directed computer use. In 
other words, instead of submitting informa- 
tion to the computer via punched cards and 
waiting for the results to appear on the 
printed edge, these designers suggested keying 
in data directly into the computer at a con- 
sole or user station and receiving back almost 
immediately the information at either loca- 
tion. The computer actions being directed by 
the human then became very diverse and flex- 
ible. Many of these have been highlighted in 
the literature 9 ' 10 , especially those relating to 
exotic military systems. 

About this time people took still a different 
—but related— approach to implementation of 
query languages at user stations". The query 
language approach borrowed heavily from the 
technical developments of problem-oriented 
languages. The resulting query language was 
highly formatted, bearing many family re- 
semblances to the conventional compiler lan- 



guages which were designed for immediate 
question and answer on-line use. 

These two developments gave rise to what 
seem to be the present three streams of effort ; 
on-line computer use, on-line problem solving, 
and on-line programming. 

PROGRAMMING STRUCTURE AND 
FUNCTIONS 

There are five major parts to the program- 
ming system of an on-line system, : the console 
and communication programs, the executive, 
the utility programs, the operating programs, 
and the data base. These are shown schemati- 
cally in Figure 5, along with the information 
flow among them. 

The console and communication program 
provide the linkage between the human and 
the system with a display console as interface. 
In some cases where information is flowing 
to and from communication devices, programs 
to handle these functions would also come 
under this category. Three major functions 
are included: input/output data buffering, 
input/output data formatting, and operator 
logic controlling. Data which is carried into 
the system at the console must be temporarily 
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buffered. Frequently a number of characters 
are buffered until an "end of message" signal 
is provided, after which the total message is 
sent to the executive program. Also, format 
changes are frequently required to shape in- 
formation to the form that the executive can 
accept. 

One of the newer concepts in operator con- 
soles is represented by operator logic control- 
ling. Under the topic computer lead pro- 
cedures described above, there is console pro- 
cedure logic which is implemented by the 
console and communication programs. These 
programs lead the operator; the steps depend 
on the state of the system and the particular 
operation being performed. They may lead 
him by providing information on the next 
step, by informing him which next console 
steps are permissible, or by signaling him 
when a console step has been initiated which 
is not permissible. Properly designed, the con- 
sole and communication programs are flexible 
and modular, and they can be modified easily 
to accommodate changing procedures. 

The executive program provides the basic 
control for the system,. It schedules all work 
to be performed; whether that work is to be 
provided by operating programs or by central- 
ized input/output. It also monitors the entire 
operation and reacts to any system interrupt 
which signals the occurrence of an undesirable 
circumstance. For example, the executive may 
be alerted when a reserved portion of the 
memory is about to be used up. The executive 
also provides the functions of controlling the 
entire operation ; that is, it initiates the vari- 
ous programming pieces and provides them 
with the operational parameters required to 
define a requested task. Last, but certainly 
not least, there is the job of synchronizing. 
In time-sharing, for example, each operator 
may receive computer time in cycles of, say, 
200 millisecond increments, allotted to him by 
the executive in synchronizing the system 
operation. 

The utility programs provide three basic 
functions: the movement of data within the 
system required by time sharing or pooled 
procedures, the controlling of the printout of 
information on a pooled basis, and the con- 
trolling of accesses to auxiliary memory. 

One of the most challenging problems in on- 
line systems is the correct design of utility 
programs which can be considered as overhead 
programs initiated by the executive program. 



Data must be moved, for example, from work- 
ing memory when the user or operator leaves 
his console. Data is constantly shuffled within 
the system to accommodate the various modes 
of system operation and the requirements 
placed on the system. Similarly, utility pro- 
grams are necessary for controlling the print- 
out of information when the printout facilities 
are to be shared by all of the users, as they 
usually are in an on-line system. Controlling 
the auxiliary memory is another utility type 
task since the bulk storage devices are usually 
shared by all. 

The last two parts of the programming sys- 
tem are the operating programs and the data 
base, the latter referring to the storage of 
intermediate or final data. The data base com- 
municates primarily with the operating pro- 
gram ; for flexibility, there is a secondary link 
to utilities. The utility routines may, at the 
request of the operating program working 
through the executive program, request utility 
programs to handle certain data in the data 
base. 

Some of the general principles to be con- 
sidered here are : 

1. Utility programs exist for the benefit of 
each system user and for the system itself. 
They are not considered part of the operat- 
ing programs, but rather they are of a gen- 
eral utility nature which is called upon by 
the executive. 

2. The executive is in reality the control de- 
vice of the system. Nothing occurs auto- 
matically within the system without its 
being initiated and monitored by the exec- 
utive program. 

3. Although the data base is a passive pro- 
gram it is included in this structure because 
the data base can itself be a computer pro- 
gram which is being operated upon by an 
operating program in an on-line program- 
ming configuration. 

THE NEW TECHNOLOGY 

On-line systems are giving rise to new hard- 
ware and software technology. Computers 
must necessarily be designed quite differently 
if they are to work efficiently in these kinds of 
systems. Also, there are a number of badly 
needed software and programming techniques 
to provide efficient and economical system 
implementation. 
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Some of the hardware aspects which need 
attention are as follows : 

1 . Memory protect hardware. This is a device 
which allows the currently operating pro- 
gram to be "locked out" of all but one part 
of the memory. The capability must be dy- 
namic and under flexible control of the ex- 
ecutive program, since the allowed operat- 
ing areas of the memory change on a milli- 
second basis. 

2. Inexpensive consoles. The computer indus- 
try must develop inexpensive consoles. A 
reasonable goal is that the console should 
sell for under $15,000, that it should have 
a cathode ray tube or something equivalent, 
that it should allow for some buffering of 
information, and that it should have a flex- 
ible and adaptable keyboard structure and 
status information display. 

3. Multi-computers. Computers must be de- 
signed which allow the incremental addition 
of modular components, the use by many 
processors of high speed random access 
memory, and the use by many processors 
of peripheral and input/output equipment. 
This implies that high speed switching de- 
vices not now incorporated in conventional 
computers be developed and integrated 
with systems. 

4. Improved input/output. The entire range 
of input/output parameters needs overhaul. 
For example, the random access memory 
device must be accessible through two to 
five channels. Channel logic and interrupt 
procedures must provide greater capability 
than they do on most present computers. 

Of equal significance are some of the new 
software techniques which need attention: 

1. Automatic segmentation. Since running 
programs will have access to only a portion 
of the memory, frequent "page turning" 
will be necessary as the program goes 
through its major operating pieces. Seg- 
menting of the program can be very diffi- 
cult if it must be done manually by the 
programmer. Assemblers or compilers with 
automatic segmentation or semi-automatic 
segmentation are needed. 

2. Relocatable programs and automatic, dy- 
namic relocation. There is the need to be 
able to produce relocatable programs, and 
to relocate these programs automatically 
and dynamically. A part of a program in 
auxiliary storage is seldom placed into the 



same spot in high speed memory from 
which it came, and the program segment is 
called into high speed memory under a 
wide variety of circumstances and con- 
ditions. 

3. Computer use and programming modifi- 
cation languages. Entirely new languages 
are needed to allow flexible and powerful 
use of the computer from remote stations. 
A standardized set of macros is needed to 
provide the user with many of the functions 
he must perform very frequently. Two of 
the simplest examples are "begin" and 
"end" instructions. These signal the system 
to make ready for the programmer's future 
activities which he may call upon the sys- 
tem to perform, and they signal the end 
of his activity to enable the system to begin 
to accommodate other activties. 

4. Console utility programs. Much of the new 
procedure revolves around the display con- 
sole. Programs and techniques are neces- 
sary to allow operator efficiency, and to 
allow the easy modifications of programs. 

5. Scheduling algorithms. Increased atten- 
tion needs to be placed on the problem of 
techniques for scheduling the many users 
with their different priorities. Priorities, 
for example, can be assigned externally or 
they can be assigned on a dynamic basis 
depending on how long the program has 
been in the system, or how much time re- 
mains before the deadline for results. 

SUMMARY AND CONCLUSIONS 

Virtually all computer applications will be- 
come on-line in the next ten years. 

"On-line" is much better terminology than 
either real-time or time shared. 

On-line applications can be considered man/ 
machine oriented or instrumentation oriented, 
the latter breaking down into three major 
on-line application areas; problem solving, 
programming and computer use. 

It is important to understand how the 
computer can assist the man in on-line appli- 
cations, and it is likewise important to realize 
that a price is paid in terms of computer time 
and programming complexity in gaining this 
user efficiency. 

On-line computer developments are in real- 
ity normal evolutionary steps which developed 
from early console and monitor system opera- 
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tion and the initial SAGE-type display con- 
soles. 

There exists a canonical structure for the 
programming system of on-line systems which 
consists of five major pieces; console and 
communication programs, executives, utilities, 
operating programs and data base. 

There are a number of challenging aspects 
in computer technology generated by on-line 
systems. Challenges in hardware designs must 
result in hardware efficiencies to meet the new 
software techniques and then the challenge 
of efficiently blending the "hard and "soft" 
for a truly efficient system.. 

Respectful attention by all computer users 
to these essential factors or opinions is neces- 
sary for the new technology to keep pace with 
the demands and the potentials. Those com- 
puter professionals who are keenly aware of 
the problems and needs, and who continue 
offering improvements, will find the chal- 
lenges stimulating and their efforts well re- 
warded. 
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Mathematical Techniques for 
On- Line Systems f 



INTRODUCTION 

My personal interest might be more nearly 
the study of mathematics and mathematical 
techniques from on-line systems than the title 
assigned me. However, the techniques which 
are currently usable for on-line systems are 
tools with which we shall expect to contrib- 
ute to the development of these new math- 
ematical ideas and techniques. 

I do not agree that "on-line" computation 
is almost synonymous with "multiple-console" 
concurrent computation. I shall consider prob- 
lems which may impose small computing loads 
and small communications requirements and 
are, therefore, also suitable for multiple-user 
operation; but that will not be my aim. One 
of the most famous multiple-user devices is 
the chalkboard (as it might be used in an 
old fashioned way to teach arithmetic or 
algebra when a sizable fraction of a class is 
sent to the chalkboard to work). A pad of 
paper and a library can provide another 
multiple-user system, at least under commu- 
nistic policies of using the paper, and under 
reasonable rules for circulation of the library 
volumes. 

Use of a single computer by several users 
concurrently is now one of the exciting sectors 
in which computers and computation are de- 
veloping. To the extent that these applications 
may make an extremely powerful, extremely 
fast, and extremely economical analogue of 
a desk calculator, the techniques are roughly 
those of a desk calculator. The functioning is 

fThe preparation of this paper was sponsored in part 
by the Office of Naval Research. Reproduction in 
whole or in part is permitted for any purpose of the 
United States Government. 



on-line, however, and such functioning is of 
interest here. 

An on-line computation has one principal 
advantage over off-line computation— the ad- 
vantage of being subject to exploitation 
through implicit decisions by the user. This 
is independent of the multiplicity of simul- 
taneous uses. The classical view of automatic 
computation (prevalent in the "remote" past 
of, say, 1958) included a high evaluation of 
austerity. Thus, then (and still in some labora- 
tories) efficient and effective use of the avail- 
able equipment required that sizable bites of 
the calculation be described explicitly. This 
was so that every decision in the course of 
the calculation of each bite could be carried 
out by the automatic machine in accordance 
with an explicit rule furnished to it in the 
coding of the problem. If a process of sequen- 
tial decision was contemplated, with decisions 
based on the calculations which had preceded 
the decision, and if the proprietor of the 
problem being processed planned to intervene 
personally at the time of decision, then either 
his intervention was seriously limited, or the 
problem would be ejected from the machine to 
await the decision (and to await the next 
period of machine operation at which it could 
be introduced, often a wait of a sizable frac- 
tion of a day). 

Men pursuing their various goals normally 
find it necessary to assign various portions 
of their problems to subordinates in an organ- 
ization. The assignments normally are of two 
types: those which can be carried out me- 
chanically without exercise of ingenuity (al- 



* Director, Computing Facility and Professor of 
Mathematics, UCLA 



25 



though a high degree of professional compe- 
tency may be required), and those which call 
for judgment and authority and which carry 
more responsibility than that of blind but 
competent obedience. The first of these types 
of assignment might be compared to use of 
compilers and computers in the austere clas- 
sical manner; the second is more like on-line 
computing. The fact that formulas cannot 
suffice for all the decisions made in the sim- 
plest of the pursuits of our lives, might indi- 
cate that the inventive process is required in 
our attempts to solve our (formally) most 
difficult problems. 

Thus, I liken the console operator of an 
on-line system to a leader of immediately and 
competently responsive subjects in attempts 
to solve problems which require exercise of 
judgement by the leader from moment to 
moment, rather than from day to day. These 
subjects comprise the computer system in- 
volved in the on-line operation. 

In all this, we must recognize that the more 
we can automate a desired operation, the more 
time we have available for obscure inventive 
processes. However, the formulation of a 
problem in terms of available procedures 
for automatic processing may impose un- 
economical difficulties. The inventor may be 
able to describe his process of invention ex- 
plicitly, but it seems likely that the energy and 
attention expended in this descriptive process 
will seriously interfere with, or even annihi- 
late, his powers of invention. 

The question of on-line mathematics is, 
then, the question of determining when im- 
plicit observation, weighing, and exercise of 
judgement involving one or more highly 
competent scientists should be preferred to 
automatic processing of data, with all ob- 
servation, weighing, and selection of sequence 
of operations left to automation operating 
under explicit rules. 

THE MATHEMATICS OF GENERAL 
SHAPES AND FORMS 

In seeking an answer to the question of 
on-line mathematics formulated above, we are 
naturally drawn to consider those qualities 
of concrete and abstract devices which are 
still efficiently recognized by and reacted to 
by humans. This immediately suggests "eye- 
balling/' and this, in turn, brings to mind 
topological aspects of mathematics, again in 



the classical sense (which this time starts 
with Gauss and continues through many of 
the contributions of the less abstract current 
contributions to topology ) . 

However, there are sensory devices which 
determine general forms and shapes which 
can be applied in non-topological ways. It 
seems to be well established that the eye can 
detect a straight line segment in a photograph 
while limited resolution and other imperfec- 
tions effectively hide the segment from auto- 
matic recognition by instruments. The power 
of the human to hear through noise is equally 
remarkable. Patterns are recognized by hu- 
mans of low intelligence, while humans of 
the highest intelligence find themselves unable 
to explain the process satisfactorily. Finally, 
the artistic fitting of theory to fact with a 
feeling that "a slight modification right there 
should do the trick" is sometimes known as 
genius; here it is essential that the theorist 
be provided with data which makes him be- 
lieve that the slight modification (or some 
modification) is needed, and that he be able 
to obtain experience which lets him "feel" 
rather than know unequivocally the proper 
direction and size of the modification. 

To list all the interfaces which allow im- 
plicit judgement and implicit recognition to 
enter into mathematical calculations would be 
undesirable here— the list would be too lengthy 
and would force me to depart from my sub- 
ject, and, besides, neither I nor anyone else 
could possibly present a complete list. We 
can only try to find the necessary interfaces 
and mathematics in an implicit way by on-line 
observation of candidates. 

Therefore, I shall turn to some examples 
of profitable on-line calculations. 

THE ISOGRAPH AND ITS TOPOLOGICAL 
PRINCIPLES 

I shall not develop the topological tools 
needed for calculation here, but I shall de- 
scribe them as I go along. An elementary 
exposition of many of them can be found in 
my paper 1 and the references in its bibli- 
ography. 

One fundamental problem which has always 
been present in algebra is the problem of find- 
ing the roots of a polynomial. An ingenious 
on-line device for using topological tools, 
properly supported electrically and electron- 
ically, has been described by R. L. Dietzold 2 . 
This was an analogue device. 
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First, I shall describe a proof of the funda- 
mental theorem of algebra because the prin- 
ciples of this proof are pertinent here. In this 
proof, I shall denote the polynomial by P and 
its argument either by a number, a symbol z, 
or another symbol to be introduced later when 
the polynomial will be evaluated at all points 
on a circle. I shall assume that the highest 
power of the argument appearing in the poly- 
nomial is n, and that the coefficient of this 
highest power differs from zero. Such a poly- 
nomial is called a polynomial of n-th degree. 
The fundamental theorem of algebra is : 

THEOREM. If F is a polynomial of n-th 
degree, where n>l, in a single complex vari- 
able, there is some argument value for which 
the value of the polynomial is 0. 

A proof is along the following lines. First, 
examine the coefficient of the zero-th power 
of the argument in P. If this coefficient is 0, 
then the proposition is correct, for then 
P( ) =0. If not, call this coefficient a Q . A poly- 
nomial is a continuous function of its com- 
plex argument to the complex plane, and hence 
for any argument value sufficiently close to 
0, that is, for any z with |z| small enough, the 



value of the polynomial will lie as close to a 
(in the complex plane) as any tolerance speci- 
fied in advance. At first we specify this toler- 
ance to be |a |/2. In particular, we take r 
to be a positive number such that 

' .£1 whenever |z|<r, 



|P(z)-a |< 
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We now consider a circle in the complex 
plane containing all values of z with absolute 
value r, where r is any positive number to 
be specified. We denote by PR(r) the set of 
values taken by the polynomial as z takes on 
all values on the circle |z|=r. For r=r Q a 
curve PR(r Q ), restrained to lie close to a Q , 
is illustrated in Figure 1. The important 
point is that the locus PR(r Q ) does not sur- 
round the point z=0. If we think of the 
circle |z|=r being traversed by a moving 
point, and of a small being at z=0 watching 
the image P(z) as z traverses this circle, 
then this being might have to move his head 
back and forth like a spectator at a tennis 
match. But when the transit of the circle 
has been finished the being at the center will 
again look at the point on PR(r ) where his 
vigil started, and his neck will be untwisted. 
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A curve looping Z - once. 

FIGURE 2 

Now consider a value r ± which is huge, its 
value to depend on the values of the co- 
efficients in the polynomial being considered. 
This value is to be taken so that the value of 
the polynomial is determined to within a few 
percent by the value of its leading term. 
Since zn can be made to overshadow the 
value of all lower powers of z by any amount, 
simply by making |z| large enough, this value 
of r 1 can be attained. If we consider PR(r 1 ), 
and view it from the point z=0, the locus 
will surround the observation point, for the 
locus zn for |z|=r is simply a circle, of radius 
rn and center at z=0, traversed n times. 
Thus, the being can now be assigned to follow 
the generation of PR(rj) as |z|=r., is trav- 
ersed, and some of the tennis viewing exer- 
cise will follow, but if the being's body is 
strapped firmly to prevent rotation, the neck 
will have to twist n times. 

The proof of the fundamental theorem of 
algebra depends on noting that, unless the 
locus PR(r) passes through the point z=0 
for some value of r between r and r.^ the 
number of twists in the neck generated by 
watching the transit of PR(r 1 ) must be the 
same as the number generated by watching 
PR(r ). Since these two numbers differ, at 
least one circle |z| = r, for which PR(r) passes 
through the point 0, exists; and this proves 
the theorem. 

The isograph used this principle in a con- 
structive way. Without going into details, I 



assert that it is a comparatively easy job to 
present PR(r) on the screen of a cathode ray 
tube for any fixed value of r in the interval 
(0,l] (that is, for 0<r<l). The operator 
starts with a low value of r and looks at the 
screen; if the curve PR(r) does not loop the 
center of the screen, his starting value is well 
chosen. He then increases the value of r until 
one of two things happens; either PR(r) 
loops the center, or the operator runs against 
the stop on the knob with which he adjusts 
the value of r. 

If the operator gets to a looping curve, he 
adjusts the value of r with care, to make sure 
that the curve actually passes through the 
point (always, of course, within the tol- 
erance set by deflection irregularities, spot 
size, and so on). Then the curve |z| = r is 
traversed slowly (and this again is an easy 
electrical assignment), and the exact point on 
this circle which gives the image is found. 
This is a root. 

(In seeking the root, the operator utilizes 
the three-dimensional character of our space 
and stands far enough in front of the cathode 
ray tube to prevent twisting his neck irrep- 
arably. ) 

All roots with absolute value not exceeding 
1 are found in this manner. Then the poly- 
nomial may be replaced by another in which 
z is replaced by 1 /z" (where "z* is the complex 
conjugate of z) ; the resulting expression is 
replaced by its complex conjugate, and this 
expression is multiplied byznto form a poly- 
nomial. This polynomial has coefficients which 
are the complex conjugates of those of the old 
polynomial— occurring in reverse order. If the 
old polynomial values were Sa^zk the new 
ones will be Sa n _^zk. 

One can argue that the topological looping 
principle is not necessary for the explanation 
of the isograph, all that is necessary is that 
the operator be sufficiently alert to perceive 
any curve PR(r) which passes through the 
point. This argument is correct so long as it 
is • convenient to vary r continuously, but in 
many cases, particularly with current designs 
of digital machines to be used on-line or off- 
line, this continuous variation is not conveni- 
ent, and the preferred method would be to try 
r=l first; if the result indicates one or more 
roots z with |z|<l, the value r =1 /£ would be 
tried, and so on. 

I shall insert here some mathematics which 
might plausibly have developed from on-line 
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computation; it is at least based on the idea 
of considering PR(1). This ingenious scheme 
is due to D. H. Lehmer 3 . It is an algorithm 
which determines whether a polynomial P 
has any roots inside the circle with center 
and radius 1. It is a completely automatic 
scheme, and it has been coded for convenient 
operation on a digital computer without op- 
erator intervention. 

To start with, it should be noted that simple 
transformations will permit the search for 
roots of a given polynomial in any circular 
disc, to be carried out by searching for roots 
of a related polynomial of the same degree 
in the unit circular disc centered at 0. All that 
is necessary is to replace z in the polynomial 
by (z-c), where c is the center of the circle 
of interest, and then to replace z in this new 
polynomial by z/r, where r is the radius of 
the circle of interest. Lehmer's search con- 
verges on roots by pinning them into always 
smaller circular discs; the general method is 
illustrated in Figure 3. 

We assume that Lehmer's algorithm to 
determine whether any given circle has any 
roots of P on its interior has been established. 
We then seek a circle (starting with the unit 
circle with center at 0) with at least one root 
interior to it. We then try a circle with the 
same center and half the radius. Thus, given 
any circle with at least one root on its interior, 




FIGURE 3 



we test the circle with half the radius and 
the same center. Assuming that the center 
is not a root, eventually we shall arrive at a 
circle of radius R with roots on its interior, 
while the concentric circle of radius R/2 has 
no roots on its interior. These two circles are 
depicted in Figure 3. There are no roots in 
the shaded region, but there are roots in 
the annular ring. Lehmer then chooses eight 
centers, c Q through c 7 in the figure. He 
chooses an initial value of 5R/12 for the 
radius, and he repeats the process for circles 
centered at each q. It is easy to show that 
these eight initial circles completely cover 
the annular ring. 

Lehmer's algorithm is the following. Let P 
be a polynomial with coefficient ak for the k-th 
power of the argument. Let Q be the related 
polynomial we constructed above; Q has co- 
efficient a n — k for the k-th power of its argu- 
ment. Now create a new polynomial 

P ^ = &q P — a^ Q. 
This is a polynomial of lower degree than P. 
If its constant term is negative, then P has a 
root inside the unit circle with center at ; if 
its constant term is positive, then it has the 
same number of roots within the unit circle 
as P. In the former case, the tracking down 
process of Figure 3 is used ; in the latter case 
the polynomial Q t related to P 1 is created, 
and the elimination of the highest power of 
the argument is repeated. Eventually, the 
process leads to a negative constant term, 
meaning that roots do exist within the unit 
circle, or to a constant polynomial with pos- 
itive value meaning that no root exists inside 
the unit circle. 

The simplest proof of this theorem seems 
to rely on the proposition that the roots of a 
polynomial are continuous functions of the co- 
efficients—a well-known proposition with few 
proofs in the literature. Although most pub- 
lished proofs involve study of symmetric 
functions, the reader can furnish his own 
proof by index arguments such as those in 
reference 1 . The proof is trivial if there are no 
multiple roots. It can be shown that if the 
constant term of P 1 is positive, then the poly- 
nomial <ja Q P— anQ can not have roots with 
absolute value 1 for any <r in the interval 
[0,1]. This argument is mildly topological. A 
proof of uniform continuity is available in 
reference 4 pp 156-158. 

Thus, the isograph attack, perhaps subtly, 
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has grown into an attack suitable for either 
on-line or off-line computation. 

However, for functions more complicated 
than polynomials, it is hard to find a suitable 
algorithm to place roots inside a simple closed 
curve bounding a region. Still the turning 
number method will frequently work. It was 
applied successfully to solve equations of the 
type P(z) e" z + Q(z)=0 by Arnold 0. Allen. 
While a deep study of equations of a particu- 
lar type might yield a better method of solu- 
tion, the old isograph principle is certainly 
the easiest to apply if the worker stumbles 
on an equation of unpredicted type for the 
first time. There was no convenient method of 
generating the graph of P(z)e" z + Q(z) for 
all z with |z| = r in the days when the isograph 
was designed, but modern digital computers 
can construct graphs of functions of a wide 
class of considerable complexity. One method 
developed and used with spectacular success 
has been developed by G. J. Culler and B. D. 
Fried 5 ; this method is described by D. A.Pope 
during this symposium. 

A BRIEF GLANCE AT OTHER 
TOPOLOGICAL PROBLEMS 

The idea of looping closed curves in 3-space 
goes back to Gauss, and generalizations of the 
turning number argument above have been 
developed. Two curves in 3-space are looped 
if every orientable surface bounded by one 
is cut by the other. The degree to which two 
curves are looped is determined immediately 
by eye, and with difficulty by a computer. The 
computer would use Gauss's integral formula : 

x-y 

dx 

dy 



J=- 



0) 



00 



[(x-y) 2] 3/2 



If J/0 the curves are looped. In the for- 
mula, x and y are parametrized closed curves 
which do not intersect each other; both x and 
y are to be considered to be vectors in 3-space. 
Vector subtraction and scalar multiplication 
of vectors are intended at appropriate places 
in the formula. 

Figure 4 depicts a pair of looping curves; 
J computed in accordance with Gauss's for- 
mula would take a value —1 or 1, depending 
on the relative orientation of the param- 



etrized curves. Also in Figure 4 is a pair of 
curves which are tangled but not looped ; they 
would give a value in Gauss's formula. Also 
related to the subject of loops and tangles is 
the subject of knots. A knotted curve is even 
hard for a novice to define ; it may be defined 
as a polygon which is not the boundary of 
a non-intersecting continuous image of a 
closed circular disc. 

All this might leave a physicist cold. How- 
ever, it is true that Gauss developed his for- 
mula in his study of magnetic forces. It is also 
true that physicists now deal with concepts 
that occur in quanta, that some of these phys- 
ical entities should be determinable by inte- 
gration around an enclosing surface or hyper- 
surface, and that integrals of the general type 
of Gauss's form the most general type of 
integer- valued integrals known. This type is 
described roughly as the integral of the solid 
angle in (m + n + l)-space swept out by a non- 
zero vector which is a continuous function of 
an orientable (m+n) -dimensional closed com- 
pact manifold. It requires little imagination to 
believe that one would rather look at the 
looped curves of Figure 4 than compute the 
value of J in the formula. 

And, finally, a word about knots. It seems 
impossible that we can not tell whether two 
knots are equivalent under reasonable tran- 
formation laws, but derivation of a complete 
set of invariants seems to be terribly difficult. 
A pessimistic approach to this problem might 
have been an attempt to create a knot whose 
reduction to some "most elementary" form 
would involve some temporary increase of 
complexity en route. I shall not stress these 
matters, however, except to note that modern 
on-line methods are easier to use than string 
and that they can be made to record all inter- 
mediate stages so that any success in experi- 
ments is automatically documented. 

I close this part of my discussion with an 
obvious remark concerning tameness require- 
ments of current systems. Generally on-line 
displays represent only tame curves. The 
UCLA version of the Culler-Fried system in- 
terpolates linearly between 125 computed 
points, thus creating a polygon or an arc 
of broken line segments. Wild curves not 
adequately described by polygonal approxi- 
mations currently are infrequently treated 
by computers. I furnish one example pre- 
sented by Ralph H. Fox 6 . It is an infinite 
sequence of crochet stitches. In the sketch I 
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A knotted curve 



have added a parallel line to the right of the 
oriented curve when one string passes over 
another. I have also added dotted lines to show 
how any finite number of stitches could be 
unravelled. It seems probable that some subtle 
method of implicit description would be re- 
quired before a computer could be called 'on 
to aid in the study of such a wild curve. 

LOW REDUNDANCY DESCRIPTORS 

One of the really powerful tools of math- 
ematical analysis is the construction of con- 
venient complete bases in Hilbert space. The 
most familiar example, perhaps, is Fourier 
series. Fourier series uses positive, zero, and 
negative integral powers of the imaginary 
exponential function as a complete basis for 
the space of functions which are of class L 2 
(square integrable in the sense of Lebesgue) 
on the interval (0,2tt). Fourier integrals fur- 
nish the same service for functions denned 
over an infinite domain. This type of con- 
sideration of a function as a vector in a vector 
space of infinitely many dimensions has great 
value in abstract studies in that (among other 
things) it permits the mathematician to prove 
the existence of solutions to various problems 
and to describe these solutions, at least in 
principle. 

A great practical value is also realized, for 
many functions described by Fourier series 



are described sufficiently well for practical 
purposes by their first few Fourier coeffi- 
cients. 

An example of this practical value is the 
familiar study of bandwidth in connection 
with radio transmission on a frequency in 
a crowded spectrum. Here, the harmonics can 
be attenuated by properly chosen filters, and 
the whole study leads (through a development 
which is familiar to or easily available to 
all readers of this paper) to fairly efficient 
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use of the available frequency spectrum in 
single side-band suppressed carrier transmis- 
sion, magnetic tape recording of digital in- 
formation, and so on (but not yet for the 
internal structure of digital computers!). The 
point is that the Fourier description of a 
function presents partial descriptors of the 
function which are adequate for the purposes 
at hand, and that only a small, wisely chosen 
part of this Fourier description needs to be 
computed or used. This part furnishes a de- 
scription of high efficiency (or low redundancy) 
for the purpose intended. 

Various practical considerations also enter 
into this picture. First, we should note that 
we have no access to really existing physical 
entities extending in time or in space both to 
— oo and to +00 . Secondly, we have no per- 
fectly periodic functions. In response to these 
philosophical objections we reply, of course, 
that our instruments are far from perfect, 
and that their reactions to the existing stimuli 
are indistinguishable from what their re- 
actions would have been to the idealized stim- 
uli which cannot exist. Thus, we stretch or 
contract quasi-periods of quasi-periodic func- 
tions where the actual application is insensi- 
tive to minor local variations in rate. 

Still considering Fourier analysis, we turn 
to the Gibbs phenomenon. The Fourier series 
might converge in the mean (that is, roughly 
in the sense of power or energy) but still miss 
the function it should approximate rather 
badly at some points. In particular, near a dis- 
continuity with different left or right limits, 
the partial sums of the Fourier series over- 
shoot by a sizable fraction of the jump at the 
discontinuity, this overjump is bounded away 
from 0. This phenomenon was noticed by 
Gibbs and probably by workers before Gibbs, 
and it undoubtedly has been rediscovered 
many times after the time of Gibbs. Untold 
labor would have been saved if the Culler- 
Fried on-line system had been available. Dr. 
Culler once demonstrated the phenomenon to 
me in about one minute starting from scratch, 
without having considered the problem before 
so far as its connection with their on-line 
system is concerned. 

Another application in which small varia- 
tions in rate of generating a pattern can some- 
times be ignored is in the study of electro- 
cardiograms. Briefly, the electric potential 
difference measured by a pair of electrodes 



attached to the skin shows one large sharp 
spike and several lower wiggles during each 
pulse cycle of a normal person. If the patterns 
of the pulse cycles are similar except for dura- 
tion of the cycle, one might try to describe 
the normal cycle by carrying out a Fourier 
description of one chosen cycle. If this is done, 
it turns out (not surprisingly) that a dis- 
couragingly large number of components is 
required to get agreement. This is a phenom- 
enon related to the large amount of spectrum 
usurped by any suddenly changing signal. 
(Radio transmitters are required to soften 
their key clicks by filtering out the higher 
harmonics, and a result is the lengthening of 
rise time and fall time of keyed signals; in 
the same way, transmitters of voice or music 
have limited bandwidth allowance so that 
they must remove some of the high frequency 
sounds necessary for high fidelity broad- 
casting.) 

This is not a failure of Fourier series, for 
the harmonic content of an electrocardiogram 
might not be a terribly useful bit of informa- 
tion in any event. However, if a formal de- 
scription of a cardiogram wave is desired 
(and I doubt that anyone will contest this), 
then the description should be in terms of a 
few numbers, and the wave synthesized from 
these numbers should have properties indis- 
tinguishable under normal examination pro- 
cedures from those of a true normal wave. 

The instrument for describing a sharp spike 
is not the Fourier instrument (unless some 
application requires spectral analysis) but 
rather some instrument like the Bernstein 
polynomial. The Bernstein polynomial is usu- 
ally defined over the interval [0,1] rather than 
[0,2tt], and I shall conform with this; unde- 
manding arithmetic adjustments must be made 
to transform its effective domain to the inter- 
val [0,2tt]. The Bernstein polynomials are 
indexed by two integers, n and v. The index n 
is always positive, and 0<v<n. The polynomial 
is defined as , . 

The quantity(^]=n!/[v!(n-'y)!] is a bi- 
nomial coefficient used to normalize the poly- 
nomial. For fixed n and v, the graph of the 
polynomial attains a maximum at x=v/n. The 
function is monotone increasing to the left 
of this maximum, and monotone decreasing 
to the right; it remains positive on the open 
interval (0,1) and takes the value at x=0 
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and x=l. As n increases, the sharpness of the 
peak increases. Professor T. S. Motzkin sug- 
gests that periodicity be restored by setting 

9 



= sin 



2tt 



While there is no apparent theoretical rea- 
son for using what seems to be an unnatural 
mixture of polynomials and sinusoidal com- 
ponents to describe a function, there may be 
sound practical reasons for using the mixture 
to provide efficient descriptions of sufficient 
accuracy for calculation. In calculation there 
is frequently no demand for a complete non- 
redundant basis, or, perhaps, the knowledge 
that such a basis exists is sufficient to guaran- 
tee the soundness of a calculation. 

The suggestion made above that Bernstein 
polynomials be used to remove troublesome 
peaks should not be interpreted to imply that 
all uses of Bernstein polynomials in computa- 
tion are efficient. For example, the polynomials 
are a means of proving the Weierstrass ap- 
proximation theorem that any continuous 
functions on [0,1] can be approximated arbi- 
trarily well by a polynomial. For the function 
f , the n-th approximation is given by 

f ~S f(v/n) B(n,<y) 

The summation is over all values of v, start- 
ing with and continuing through n. The use 
of the polynomials to prove the Weierstrass 
theorem is convenient. Roughly, the proof con- 
sists of showing that the method works for 
any quadratic function, noticing that the ap- 
proximation is monotone in the sense that if 
g>f for every point on [0,1], then the n-th 
approximation to g is nowhere smaller than 
the n-th approximation to f , and finally that 
any continuous function can be squeezed arbi- 
trarily closely at any point by two quadratic 
functions, one of which is nowhere smaller 
than the squeezed function and the other is 
nowhere larger than the squeezed function. 

Even though this is a convenient line of 
proof, there are usually more efficient ways of 
expressing a polynomial approximation to a 
function ; these include the classical interpola- 
tion polynomials, which are easily computed; 
although they may not converge to the func- 
tion approximated. 

However, with good display and reasonably 
powerful means of computation, an on-line 
system might reveal the adequacy or inad- 
equacy of a set of descriptors, and an ingeni- 
ous operator might note peculiarities of the 
residue after a partial description, and might 



use these peculiarities to furnish progressing 
low redundancy descriptions. 

I cannot stress too highly the value of such 
descriptors. Those of you who have dealt with 
the problem of recognizing patterns must rec- 
ognize that labored descriptors, which are in 
some sense adequate from the point of view 
of a mathematical theorem, are inefficient and 
at least inadequate (more likely impossible) 
from a constructive computational point of 
view. With all this, however, we have few tools 
at hand to use in abandoning classical math- 
ematical approaches toward description. The 
on-line systems now developing present a fine 
opportunity for augmenting our knowledge, 
or at least our practice, in this important field. 
Use of descriptors which are not orthogonal 
and do not form a linear set becomes difficult 
in classical functional analysis, but we can 
still use on-line displays from powerful com- 
puters to experiment. In short, then, one of 
the fields in which great interaction between 
formal manipulative mathematics and schol- 
arly computation can be expected is the field 
of convenient description of functions or other 
mathematical entities. This description is clas- 
sical through measure of interaction with 
each of a set of test entities, and our new 
power, if one is found, will lie in the enhance- 
ment of the allowable classes of testing enti- 
ties, so that interaction between themselves, 
for example, can be tolerated more easily. An 
application of a low redundancy description 
might typically be construction of a Wiener- 
Hopf type of filter 7 to remove unwanted sig- 
nals in a record, and to preserve the desirable 
ones. In some cases, it might be more conveni- 
ent to use a small number of low redundancy 
descriptors abstractly than to subject large 
quantities of data to spectral analysis. 

One field in which careful plotting and 
measuring might be substantially aided by 
good on-line displays is in the rational de- 
scription of functions. This system of approxi- 
mation was described and developed by Cheb- 
yshev, perhaps reintroduced by Hastings and 
his coworkers 8 , augmented with tables by C. 
Lanczos', and applied in many laboratories 
with automatic computers. A recent presenta- 
tion has become available through work spon- 
sored by Control Data Corporation and par- 
ticipated in by Hans Maehly and many associ- 
ates 10 . The set of approximations in this last 
reference is a fine set to consider in connec- 
tion with on-line systems where the aproxima- 
tions might be suitable. 



33 



I close this discussion of description by 
noting one additional development of our times 
which will certainly continue to interact 
strongly with on-line use of computers, and, 
for that matter, with development of computer 
languages for on-line or off-line use, and with 
more subtle uses of computers in the future. 
This is the development of quantitative stud- 
ies of the conceptual aspects of all the 
communications sciences. This exciting field 
crosses many boundaries of classical factoring 
of scientific disciplines— biology, physics, engi- 
neering, psychology, linguistics, mathematics, 
and many separate divisions within these 
disciplines. One might profitably spend a few 
minutes considering what these newly expand- 
ing studies imply in connection with computa- 
tion, and especially on-line computation. In 
this contemplation, the titles of the lectures of 
a series of lectures starting at UCLA might 
be illuminating. I present a list of titles as 
bibliographic references 11 . 

QUESTIONS OF STABILITY 
It becomes clear that no one paper nor book 
can possibly describe the mathematics appro- 
riate for on-line computation. We all have rec- 
ognized the growing awareness among appli- 
ers of mathematics to questions of stability. 
Perhaps one of the most valuable contribu- 
tions made to mathematics by analogue equip- 
ment used during the last twenty-five years 
has been this growing awareness. Mathemati- 
cians have reviewed their work, and tech- 
niques have been discarded. Engineers have 
designed damping features with much greater 
care than was exercised in earlier times. The 
pace of current life has forced utilization of 
these studies of stability. 

Where linear models are adequate, the anal- 
ysis of stability is comparatively straightfor- 
ward. However, as we become more and more 
dependent on models which are not adequately 
descriptive after linearization, these stability 
studies become more difficult and probably 
more important. It seems to me that we might 
expect on-line systems tailored for a class of 
stability studies as we develop greater needs 
for understanding the behavior of complicated 
non-linear reactors. The study which may de- 
velop into such systems is already being car- 
ried out in many different ways in many dif- 
ferent places. I note the activities of the group 
called RIAS, first as a part of The Martin 
Company, in Baltimore, and more recently at 



Brown University. There under the leadership 
of Professor J. P. LaSalle and the inspiration 
of Professor S. Lefschetz, a productive group 
has developed many techniques which have 
not yet been widely applied to on-line analysis 
and simulation. At UCLA, other studies are 
progressing, and these are more or less typical 
of the type of thing developing at many 
places. They, too, tend to ferret out instabili- 
ties and near instabilities through computa- 
tion, although the basic hope is usually to 
choose a technique which will be stable in the 
solution of some special problem in which in- 
stability is a nuisance, and not something to 
be studied for itself. 

I look forward to further developments of 
our on-line systems to take into account the 
information now being accumulated and doc- 
umented so that subtle, sensitive and more 
reliable simulations can be undertaken to de- 
termine behavior of complicated systems. I 
feel that on-line computation will contribute 
materially to this. 

And, finally, I note that, except for physical 
control purposes, on-line computation has a 
kind of built-in suicide. As we learn more 
through its use, we must hope to formulate 
this knowledge, so that it is available without 
human judgement and intervention. In short, 
it must be included in the repertoire available 
for explicit off-line computing in much the 
same way as the development of D. H. Leh- 
mer's technique, mentioned above, has enabled 
us to replace the isograph in solving poly- 
nomial equations. 

ADDITIONAL TOPICS 
I list here, mainly without reference, topics 
which now demand computational attention- 
most of it on-line. 

In one-dimensional problems of the calculus 
of variations and in many similar problems, 
ordinary differential equations with end con- 
ditions arise. These may be solved by gradiant 
or relaxation methods, but such solution is 
frequently extremely laborious. On the other 
hand, they may be solved by initial value 
methods, creating a field of solutions with 
one to be chosen to pass through the second 
end point. 

There seems to be some purpose in combin- 
ing these two schemes. By on-line (or later, 
off-line) experimentation one might seek a 
well computed solution which passes close to 
the second end point. Then in some cases 
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perturbation methods applied to this solution 
through relaxation methods might give a very 
accurate solution with correct end values. I 
believe that experiments along these lines are 
planned at our Computing Facility by D. A. 
Pope and by James Dyer. 

Similar studies might be applied to stochas- 
tic population process problems. These prob- 
lems may yield partial differential equations 
or very large systems of ordinary differential 
equations. Some type of scaling experiments 
are well worth while in an effort to replace 
either system of equations by a set of ordinary 
equations small enough to be handled. 

Another interesting study in stochastic 
population processes is the nature of config- 
urations which are almost stable. In various 
attritive processes, a condition of almost sta- 
bility occurs even though it is clear that com- 
plete annihilation of the population must 
eventually occur with probability one under 
the model used. Simulation of such situations 
seems attractive. 

Other on-line simulations are desirable for 
the generation of models, for training pur- 
poses, and so on. The Link Trainers, intro- 
duced many years ago and improved since 
then, are famous examples of on-line compu- 
tation somewhat specialized. Other training 
functions have been carried out spectacularly 
at the System Development Corporation. We 
still need models, systems, and simulation of 
highway traffic control and air traffic control. 
The UCLA Institute of Transportation and 
Traffic Engineering is carrying out interesting 
highway traffic studies, including many on- 
line simulations. The air traffic control studies 
are far less productive than one would have 
estimated ten years ago. They may have been 
hampered by poor models, on-line equipment 
inadequate for the purpose, or by other de- 
terrent conditions. One thing which seems 
clear is the controlled traffic must be assigned 
to parametrized trajectory (the parameter 
being time) from take-off to touchdown. Thus, 
the awkward holding patterns used in the 
past (in which aircraft cruising at speeds in 
excess of a hundred knots pretend that they 
sit still to await their landing turn) must con- 
tinue to be revised into long trajectory assign- 
ments terminating (hopefully) in routine 
landings. 

Many of us would prefer that radical mod- 
ifications of the approach and landing pro- 
cedures be simulated first and then tried out 



on aircraft removed from our own position by 
some considerable distance. 

Continuation of this list seems pointless. 
About the only thing to say is that simulation 
generally means that the result of some activ- 
ity is estimated without actually going through 
the action. Newton's second law of motion is 
a simulation under this description— and I be- 
lieve that it is best to accept this. Simulation 
is, of course, essential to the continuation of 
our ordered lives, and every plan is a result 
of some sort of simulation. Under these con- 
ditions, it seems clear that simulation of 
material activities will resume its place of 
exciting importance as the present trend of 
building up powerful on-line computing math- 
ematical methods and computing and console 
response continues. 
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Multi-Computers Applied to 
On-Line Systems 



The principal motivations for multiplicity 
of components functioning in an on-line sys- 
tem are to provide increased capacity or in- 
creased availability or both. The selection of 
a configuration should be based on sound 
economic valuation, just as the selection of 
the goals of the on-line system itself must be 
determined. 

The use of multi-computers implies inter- 
communication, with the associated implica- 
tions of interconnection, reconfiguration and 
interlocking. Some of the techniques, alterna- 
tives and effects of these implications are 
discussed. 

CAPACITY 

Although one of the principal reasons for 
multiplying components in a system is that 
of increased capacity, the efficacy of this pro- 
cedure is not uniformly good. Generally multi- 
plication for capacity is an economically de- 
sirable approach only for those components 
whose capacity is limited by technology. This 
is particularly true at present in electrome- 
chanical devices, such as peripheral storage 
and input/output (I/O) components. It is 
less true for electronic devices such as memory 
and central processing units (CPU's), in that 
order. In CPU's, adequate examples exist to 
demonstrate that doubling the component 
count more than doubles the performance, 
whereas duplexing the CPU less than doubles 
the performance. Doubling the cost of a mem- 
ory would probably more than double its ac- 
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cess rate, or certainly more than double its 
capacity, but probably not both simultaneously. 

When multiplication is the most efficacious 
way to increase capacity, one can not expect 
a rate of capacity increase as great as the 
increase in components. The closest approach 
to a linear improvement can be achieved if 
the components can be partitioned, either for 
concurrent correlated use (such as in tape 
sorting) or concurrent independent use (such 
as spooling). The only factor limiting linear 
improvement in this circumstance is non-uni- 
form loading, which almost always occurs. 
The second closest approach, and the only other 
technique known to this author, to linear im- 
provement is by distributing, so that statisti- 
cally a multiplicity of like functions can be 
performed concurrently. This can not always 
be done, for example, in printing, but can 
generally be done if extra-functional con- 
straints do not make the component dedicated 
for extended time periods. To exploit the 
increase of capacity gained by distributing, 
the system must provide for queuing. The 
queue depth permissible should be at least as 
great as the number of components over which 
the function is distributed. 

If more than one CPU resides in the system, 
another advantage of the multiplicity of other 
components appears. This advantage derives 
from the common pooling of equipment, even 
though the computer tasks may be independ- 
ent. By pooling, the number of components 
provided need not be large enough to accom- 
modate peak requirements occurring concur- 
rently in each computer, but may instead 
accommodate a peak in one occurring at the 



38 



same time as an average requirement in the 
other. 

Even though the capacity increase due to 
multiplication grows less rapidly than linearly, 
the hardware complement grows more rapidly 
than linearly. The additional hardware is re- 
quired to provide the gating, selection, priority 
determination, and power needed to make the 
desired interconnection. This added circuitry 
not only increases hardware costs, but also 
reflects in increased failure rates and increased 
transmission delay. The increased transmis- 
sion delay may be crucial in shared electronic 
memory, for the CPU-memory communication 
time is quite critical if the CPU is designed to 
attain maximum performance in combination 
with this memory. 

A further precaution to observe when in- 
creasing capacity by multiplication is that even 
though functions may distribute very nicely 
in a statistical sense, not all devices are satis- 
fied by good statistics. A prime example of 
this occurs in the use of shared electronic 
memories to accept or provide data to two 
or more high speed I/O devices concurrently. 
In this situation, even though the effective 
bandwidth is more than adequate to match 
the sum of the I/O device bandwidths, the 
interference, and consequent delays, may cause 
one or both devices to overrun. Overcoming 
this difficulty requires the inclusion of buffer- 
ing to average the peak requirement to the 
effective bandwidth of the shared memory. 

An alternative to multiplication is sometimes 
available, particularly in the CPU. This alter- 
native consists of separating specialized func- 
tions from the CPU workload and providing 
a separate independent specialized component 
for this purpose. This approach is commonly 
taken in single computer systems, the most 
common example being I/O channels. This is 
also the essential point in those systems where 
a separate limited function, quite highly spe- 
cialized, I/O control computer is introduced. 
In these particular systems, a performance 
gain can be greater than linear with respect 
to hardware increase. At present, there are 
not too many heavily employed specialized 
functions that are identified and substantiated, 
but this approach provides the greatest capac- 
ity gain payoff when it is applicable. 

AVAILABILITY 
The structure of a multi-computer system 
planned for high availability is principally 



determined by the permissible reconfiguration 
time and the ability to fail safely or softly. The 
multiplicity and modularity of system com- 
ponents should be chosen to provide the most 
economical realization of these requirements. 

The system components involved in a given 
task form a configuration. The process of 
eliminating and introducing components when 
changing tasks is reconfiguration. The time 
required to reconfigure upon occurrence of a 
malfunction may be a critical system param- 
eter. This reconfiguration time includes the 
time required for fault detection, fault loca- 
tion, switching, possible manual intervention, 
program restart, as well as supervisory pro- 
gram execution. If the lack of this faulty com- 
ponent requires performing the tasks in a 
different manner, new programs for the alter- 
native procedures must be acquired. 

The minimum reconfiguration time achiev- 
able appears in a duplexed pair of computer 
systems, each performing the task independ- 
ently. If a component malfunctions, the re- 
configuration time consists only of fault detec- 
tion, fault location (to one of two computers), 
and possible switching of computer outputs to 
the on-line system. The supervisory task can 
be held to a minimum, and can even be im- 
plemented in hardware. 

A multi-computer system which can perform 
the full set of tasks in the presence of a single 
malfunction is fail-safe. Such a system re- 
quires at least one more unit of each type of 
system component, with the inter-connection 
circuitry to permit it to replace any of its type 
in any configuration. More than one additional 
component is needed if a type serves as a 
repository for essential system information as 
well as other functions. Also, isolation must 
be provided, so that failure of one component 
cannot cause any other component to which 
it is attached to fail as well. The duplexed 
system described earlier is fail-safe. 

A multi-computer system which can per- 
form a satisfactory subset of its tasks in the 
presence of a malfunction is fail-soft. The 
set of tasks which must still be performed to 
provide a satisfactory though degraded level 
of operation, determines the minimum number 
of each component required after a failure of 
one of its type. Similarly the full set of tasks 
determines the maximum number of each com- 
ponent required, unless, of course, this num- 
ber is not at least one greater than the mini- 
mum. Typically the fail-soft system consists of 
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two CPU's with a complement of I/O and 
storage. If the CPU's are unequal in power, 
the smaller must be capable of providing the 
necessary degraded performance. Any excess 
capacity in the fully operative system can be 
exploited by running diagnostic programs to 
detect potential or actual malfunction before 
production processing is affected. Significant 
advantages accrue if the CPU's are logically 
equivalent, even if not of equal performance. 
Such compatibility permits interchangeable 
programs and procedures which may multiply 
to accommodate to the various degraded con- 
figurations. Not only a smaller number of pro- 
grams need be written, but also a smaller 
number need be retained in electronic memory, 
permitting more effective use of this always 
insufficiently provided commodity. 

The degree of integration of the components 
used in the system may affect the availability 
as well as the cost of the system. Integration 
means combining two or more logically in- 
dependent and separately interconnectable 
components so that common equipment is 
shared. The shareable equipment may be 
frames, power supplies, and even major por- 
tions of logic and data flow. It may even 
include common, but separately controllable, 
interconnection circuitry, if sources or desti- 
nations of data are common. The principal 
factors to consider when determining the de- 
gree of integration are the cost and circuit 
reductions achieved compared to the probable 
performance loss due to interference in the 
use of shared paths and vulnerability to the 
loss of both functional entities if common 
equipment fails. There are several reasons 
why the vulnerability to loss of both functions 
need not necessarily reduce the availability 
of the system. Firstly, if interconnection cir- 
cuitry is common, the mating interconnection 
circuitry in the adjoining components is re- 
duced equally. Secondly, the degraded system 
arrived at by failure of one function may not 
be able to exploit the second. Thirdly, the 
integrated components' functions may both be 
required for diagnosing the failing part. In 
practice, multi-computer systems are defined 
in which the integrated structures are sig- 
nificantly less costly and have somewhat 
greater availability with only a minimal loss 
of capacity arising from data path sharing. 

COMMUNICATION AND 
INTERCONNECTION 
So that the CPU's in a multi-computer sys- 



tem can function cooperatively, some com- 
munication between them is necessary. To be 
reasonably effective, two kinds of communica- 
tion should be provided— a control signalling 
system which allows each CPU to gain the 
attention of the other, and a means of ex- 
changing reasonably large quantities of infor- 
mation. The information exchange can be 
either by transmitting information between 
the CPU's over a connecting link, or by giving 
them access to a shared storage medium. The 
control signalling can be a separate connecting 
link or can be in common with the transmis- 
sion link, if present. It should be able to ini- 
tiate interruptions. 

The transmission interconnection can be 
made for either local or remote CPU's in a 
system. For local transmission, a common 
control unit can be connected between chan- 
nels of the CPU's, the control unit effectively 
making one channel appear to be sending in- 
formation to a peripheral device and the other 
appearing to be receiving from a peripheral 
device. By such a tactic it is possible to achieve 
high speed transmission rates while utilizing 
existing system components for the major 
functions, and also permitting concurrent 
operation of both CPU's involved. For remote 
transmission a control unit is needed at both 
terminals of the transmission line with as- 
sociated modulation-demodulation interfacing 
to provide proper operation. Since sending and 
receiving are essentially simultaneous, proper 
control signalling must preface transmission 
to establish rapport between the CPU's. 

When two or more CPU's have access to 
a common storage medium, information placed 
in this medium by one CPU can be read by 
another CPU. In contrast to transmission, 
recording and retrieving are not simultane- 
ous nor necessarily performed by different 
CPU's. Communication, differing in applica- 
tion and probably in implementation, is 
achieved by sharing of electronic memory, 
drums, disk files, or tape drives. 

Shared electronic memory is useful for 
storage of common data and programs; in 
particular, the system supervisory programs 
and associated system status and component 
allocation data. Shared memory also permits 
distribution of tasks between CPU's on a more 
finely divisible basis, for the reconfiguration 
time for program switching of just the CPU 
is relatively very short. Shared drums and 
disk files are very useful for restart infor- 
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mation, permitting recovery on reconfigura- 
tion after malfunction. These shared peri- 
pheral storage devices also provide the capa- 
bility for maintenance of a common program 
library which is useful not only for recon- 
figuration but also for the majority of pro- 
grams normally required but not currently 
residing in electronic memory. 

Shared storage media can appear in a num- 
ber of configurations. All storage components 
of a given type may be shared, or some may 
be shared, while others are retained for pri- 
vate use by a CPU. For shared peripheral 
storage devices, the sharing interconnections 
may take place at several levels. Firstly, a 
pool of devices may be shared by several con- 
trol units, permitting concurrent operation of 
a separate device by each control unit. Sec- 
ondly, a group of control units may be shared 
by several channels, permitting concurrent 
operation of a separate control unit by each 
channel. Thirdly, the channels may be shared 
between CPU's, permitting partitioning of 
these facilities according to task requirements. 
The sharing of devices among control units is 
particularly important if a number of the 
devices become dedicated to particular roles 
in performance of a task. This applies to 
tape drives in sorting operations, and in this 
example the ability to share drives by pairs 
significantly improves the operation. For disk 
files and drums a single control unit frequently 
suffices for several devices, since each can 
play several roles within one task/Sharing of 
the control unit provides an effective sharing 
technique. If electronic memory is shared, the 
sharing of channels between CPU's need not 
necessarily involve any additional physical 
interconnection since the CPU desiring the 
channel function need not necessarily be the 
CPU which physically asks the channel to 
start in order to get equivalent action. 

An additional point in shared electronic 
memory is that the commonly accessible por- 
tions should have the same addresses when 
referenced by different CPU's. By maintain- 
ing this convention, any CPU can pick up a 
partially completed task and begin execution 
from the current point. If addresses were not 
identical, the CPU would have to return to 
some earlier appropriate restart point and be- 
gin from there. 

The interconnection circuitry which per- 
mits N out of M units to be operated concur- 
rently by N controllers is an NXM crossbar 



switch. The crossbar switch may be built as 
a stand-alone unit, which then requires its 
own frame and power supply. It may also be 
distributed among either the controlled units 
or the controlling units, in which case it can 
be integrated to share frames and power. If 
distributed among controlled units, N points 
appear in each unit. If distributed among 
controlling units, M points appear in each. 
Usually there is no particularly strong reason 
to choose one over the other. For electronic 
memory, where transmission delays are very 
important, the distribution through memory 
units is more favorable, because priorities 
may be determined and put into effect slightly 
faster. 

SOME DESIRABLE CHARACTERISTICS 
In a multi-computer system designed for 
high availability, it is not sufficient to back 
up components with other components; it is 
also necessary to determine when and how 
this backup should take place. For this reason, 
extensive checking is very important. The de- 
sign of the components should also be such 
that if they fail they do not cause malfunction 
of components with which they interface Such 
events as power failure introducing spurious 
pulses on the interface, or circuit failure hold- 
ing an interface line at an inappropriate level, 
should be carefully investigated. These occur- 
rences can make it almost impossible for the 
system to accomplish its own recovery. 

If interrupts involve the use of defined mem- 
ory locations, provision should be made to 
permit redefinition of these locations. If these 
locations are redefined, a CPU becomes in- 
dependent of a specific memory unit for its 
operation. 

Use of shared electronic memory permits 
several CPU's to alternately run supervisory 
programs. Since any one CPU does not know 
what any other CPU is doing at a particular 
instant, it is probable that two will vie for 
the same role at some time. So that chaos does 
not result, means for breaking such ties must 
be provided. The tie breaking can be per- 
formed by a reasonably simple program, but 
if this program is repeated too many places, 
its use is onerous. It is preferable to supply 
an instruction for the tie breaking facility 
required. 

For a fully automatic system, it is impera- 
tive that the allocation of system resources be 
under control of a supervisory program. Pro- 
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vision for this control may be made by includ- 
ing the following characteristics : 

1 . A supervisory mode with associated privi- 
leged instructions which must be used to 
allocate a resource initially, but not neces- 
sarily control its use after allocation. 

2. Storage protection to ensure survival of the 
supervisory program and its resource al- 
location data, with storage protection 
changes performed only by privileged in- 
structions. 

3. Hardware monitoring of changes in system 
component status with the ability to re- 
turn the CPU control to the supervisory 
program by interrupting current processing. 

4. An interval timer to return control periodic- 
ally to the supervisory program, so it can 
take stock of the system status. 

5. A wait state, sensitive to interrupts, avail- 
able to the supervisory program, rather 
than a stop or halt instruction available to 
other programs. 

By means of these provisions, a multi-com- 
puter system can be made capable of sustain- 
ing an on-line status in spite of a wide variety 
of possible circumstances which can arise in 
practice. 



SUMMARY 

The use of multi-computers in on-line sys- 
tems is clearly of growing importance as these 
new applications continue to be formulated 
and developed. The multiplication of compo- 
nents in these on-line systems is not a desir- 
able end in itself, for their usage efficiency per 
unit drops and many new problems are intro- 
duced. This multiplication does, however, pro- 
vide for capacity gains not otherwise achiev- 
able and for system availability of very high 
level. Without these gains in sight, the useful 
on-line system applications would be quite re- 
stricted. 

On-line application itself implies the need 
for certain system characteristics. Such char- 
acteristics provide the ability to remain re- 
sponsive by controlling the marshalling of 
system resources to best meet the current 
needs. Such marshalling requires the ability 
to reconfigure to exclude malfunctioning units 
or to reallocate assigned units when necessary. 
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On-Line User Languages 1 



The title suggests that there is some differ- 
ence between on-line and off-line user lan- 
guages. The fact that such a paper was 
invited at all at this time suggests further 
that there is a renewed interest in that dis- 
tinction. I say "renewed" because our experi- 
ence with computer languages began with 
on-line systems. Those of us who are now 
privileged to have on-line access to large scale 
computers often have a distinct deja vu feel- 
ing; we have been there before. Of course we 
have. It was in those far away days when the 
only way to communicate with computers was 
by the direct coupled input/output devices 
euphemistically called "consoles", often con- 
sisting of arrays of switches and buttons of 
such bewildering complexity as to provide a 
challenge to a modern airplane pilot. A little 
later, some computers were designed by peo- 
ple who had actually used earlier models them- 
selves. That accounts for the appearance of 
typewriters on some early machines. Many 
of the modern small machines are direct de- 
scendants of these early models, differing from 
them only in that they have core memories 
in place of drums or mercury delay lines, and 
in that they are very much cheaper. The early 
machines were operated in an on-line mode 
because techniques for efficient batch process- 
ing were not yet developed, today's small 
macKines are operated that way because their 
economics are not prohibitive. On the con- 
trary, most large scale computer systems are 
not operated in an on-line mode because the 
economics of such operation are prohibitive. 
I shall return to the economic question below. 
For the moment, I wish merely to implant 
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the idea that, were it not for economic con- 
straints, most computer users— certainly most 
programmers— would prefer to deal with a 
computer on-line. 

It is sometimes suggested that a very large 
fraction of computer time is used in running 
programs merely to find out why they do not 
work. Whatever the statistics might be, it is 
certainly true that debugging of programs is 
one of the chief preoccupations of computer 
users. But it ought to be remembered that a 
program is somebody's strategy for solving 
some problem, no matter whether that pro- 
gram has bugs in it or not. The debugging of 
a program is another problem. It is such a 
common one that sets of techniques for attack- 
ing it emerge out of the common experience. 

What is really going on when a program- 
mer is engaged in debugging his code? In 
effect he is doing science. By this I mean that 
he is interrogating some ill understood aspect 
of nature. He forms hypotheses based on his 
current understanding, designs and applies 
tests for verifying them, intellectually ana- 
lyzes the outcomes of his experiments, modi- 
fies his hypotheses, and so on. When he finally 
understands the nature of a particular bug, 
he modifies his code to remove the difficulty. 
The crucial difference between this kind of 
activity and that of writing programs is that 
debugging is an exploration of a solution 
space with the aid of a computer, while the 
latter is merely the encoding of solutions 
already arrived at by other means! We all 
know how absolutely necessary the computer 
is to the debugging process. It is difficult to 
the point of impossibility to diagnose an ail- 
ing program by pure reason alone. This then 
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explains why the first language systems which 
can truly be classified as "on-line" were those, 
like DDT for PDP-1, designed as debugging 
aids. 

What I am really trying to emphasize by 
this argument is the principal operational 
advantage to being on-line with a computer; 
namely, that that mode of operation permits 
the computer aided exploration of solution 
spaces, as opposed to the mere exercise of pro- 
grams representing solutions already encoded. 
It seems to me that the facilitation of this 
exploratory use of computers is the entire aim 
and direction of all work in computer lan- 
guage development, and of all computer sys- 
tems design not motivated by pure data 
reduction requirements. It follows then, that 
on-line computer languages should be looked 
upon from this point of view, and judged on 
the basis of criteria derived accordingly. 

On-line access to large scale computer sys- 
tems has now been made possible as a conse- 
quence of the development of sophisticated 
time sharing systems, such as the ones of 
which Project MAC, at the Massachusetts 
Institute of Technology, is an example. While 
it is no doubt appropriate to list the various 
on-line languages which have been developed 
within Project MAC, and to catalogue their 
characteristics, it is perhaps more useful to 
first call attention to an important difference 
between simply having on-line access to a 
large computer system and having on-line 
access to a large time shared computer sys- 
tem. A user having his own IBM 7094 has 
access to whatever software happens to come 
with his machine plus all he manages to add 
to the library as a consequence of his own 
efforts. A time shared system, on the other 
hand, is constantly enriched by the combined 
efforts of all its participants. Our experience 
with Project MAC underlines the importance 
of this distinction with very great force. Of 
course, an extensive executive system is re- 
quired to make programs developed by any- 
one available to everyone, and to honor con- 
straints imposed by program and file protec- 
tion conventions at the same time. However, 
the operation of a time shared computer sys- 
tem demands a complex executive program in 
any case; not much more is needed to meet 
this somewhat expanded goal. 

The above observations are relevant to the 
discussion of on-line user languages in that 
the various system commands which are, so 



to speak, at the fingertips of the user of the 
time shared system, constitute a kind of on- 
line language in themselves. As it happens, no 
one has taken the set of such commands 
within Project MAC and codified them in, say, 
Backus Normal Form. That may, in fact, not 
be possible. If it is not, then this must be 
because this set is very much ad hoc. But, 
lest this be taken as a criticism, let me add 
quickly that it follows from the very way in 
which such commands are added that no strict 
advance plans can be made. It is not possible 
to predict, after all, when some user may 
come up with something of general interest 
and utility. 

For the present purpose, we may look upon 
the time sharing executive as an elaborate 
interpretive program. Most interpreters have 
some mechanism for getting at the "next" in- 
struction. There may be a pseudo program 
counter, for example. The time sharing execu- 
tive gets its "next" instruction from the input 
buffer associated with a currently active pro- 
gram whenever that program has ascended, 
so to speak, to the system level. The set of 
instructions which it will understand, and to 
which it will respond, constitutes the set of 
"system commands" alluded to above. The 
"interpreter" itself imposes some syntactic 
constraints on the sequences of commands it 
will accept (e.g. certain sequences of com- 
mands are ungrammatical). The view of the 
time sharing executive as an on-line language 
structure is reinforced when it is noted that 
it is possible (within the MAC system) to file 
chains of system commands, i.e., in effect, to 
write a program in the vocabulary provided 
by the set of system commands, such that 
when that program is subsequently executed, 
the effect is as if each command were typed 
in separately and in sequence after the previ- 
ous command has been obeyed. One way of 
making a new program, i.e., one written by 
one of the MAC users, publicly available to all 
MAC users, is to modify the interpreter to 
enable it to respond to a new instruction, 
namely, that which loads that new program 
into core when called upon, and prepares it 
for execution. 

There are, however, certain languages 
within the MAC system which may be charac- 
terized as "on-line languages" in a more con- 
ventional sense. These all share the property 
that they are interpreters. (I use the word 
"interpreter" somewhat guardedly for I do 
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not believe that a very precise distinction be- 
tween interpretation and compilation can be 
made— nor do I believe that such dichotomies 
are useful.) Clearly an on-line language 
within a time sharing system should have the 
property that its user be able to engage the 
machine in more or less intimate conversa- 
tion ; i.e., to exchange messages with it on a 
give and take basis and with human tolerable 
frequency. This means that the user will write 
generally very short programs leading to in- 
termediate results, on the basis of which he 
then decides on his next course of action. It is 
fairly obvious, and indeed it proves to be so 
in practice, that this mode of operating a pro- 
gram contributes greatly to the kind of ex- 
ploratory use of the computer mentioned 
earlier. An important consequence of such 
operating practice is that the programmer 
does not have to anticipate every possible 
eventuality and account for it somehow in 
his program (even if only to provide an error 
exit) . 

Any already existing interpretive system 
(e.g. LISP), which normally expects its in- 
puts in the form of sequences of cards, and 
delivers its outputs to either tape or printers, 
can easily be modified to look for its inputs 
from the typewriter console, and deliver its 
outputs to the same instrument. One such pro- 
gramming system is an interpretive version 
of SLIP augmented by arithmetic and control 
functions. This system is called OPL (On-Line 
Programming Language). Up to a point, 
OPL's architecture is a prototype for a num- 
ber of other such systems operational in MAC. 

The basic input to OPL is a list structure. 
Generally speaking, an input list structure 
contains a number of expressions in func- 
tional notation; for example, "LOG(SQRT- 
(X))", separated by "$". All the functional 
operators, except the four basic arithmetic 
operators and " = ", are prefix operators; the 
exceptions are infix operators. Since, in more 
or less standard list notation, a "(" denotes 
the beginning of a list or sublist, and a ")" 
the end of one such, the input list structure 
is already in the form of a tree by the time 
it needs to be interpreted by the OPL ma- 
chinery. OPL is itself written in SLIP, and 
SLIP list processing operators are used to 
administer the entire interpretive process. 
This means that a large part of the SLIP 
library must be in core during the interpre- 
tive cycle. Since this is necessary in any case, 



the same SLIP functions used by OPL inter- 
nally may as well be made available to the 
OPL user explicitly. OPL, therefore, contains 
a table (essentially a large transfer vector) 
which associates with the name of each avail- 
able SLIP function the entry point to that 
function. The same table similarly gives the 
entry points to the non-SLIP functions which 
round out the OPL system. 

The final result is a quite general purpose 
programming language of a power roughly 
equivalent to that of LISP. It is, however, 
considerably more mnemonic than the latter. 
Since it was designed to be an on-line lan- 
guage, it has certain features which merely 
transformed interpreters, arising out of dif- 
ferent motivations, do not (but could easily 
be made to) have. One example of such a 
feature is that a previously undefined function 
may be called in a program (no matter how 
deeply nested). When the call is encountered, 
a message is typed out that an undefined oper- 
ation has been encountered, and the program 
held in abeyance until the programmer enters 
a program defining that function. From then 
on (and for the purposes of that program) the 
newly defined function behaves just as any 
other built-in or previously defined function. 

OPL programs and their associated data 
structures may, of course, be stored on the 
disk. The OPL user may, therefore, build up 
very complex data structures over a long pe- 
riod of time, experiment with them on line 
whenever he wishes, and freeze them in inter- 
mediate states for subsequent exploration. A 
simulation of the effects of various organiza- 
tions of a business firm may, for example, 
start with a quite simply developed tree repre- 
sentation of a small firm. Programs which 
compute differing budgeting strategies for 
such a firm may be exercised on line, and the 
most interesting ones saved on the disk file. 
As experience with the behavior of the model 
accumulates, the firm can gradually be grown 
both in size and complexity. The model maker 
may sit at his typewriter for hours, pushing 
the model around, modifying it, testing its 
sensitivity to this or that. In the process he 
is, of course, spending most of his time think- 
ing—in fact he is using (and being charged 
for) very little machine time. At some point 
he will store his program in its then current 
state to continue manipulating it a few hours, 
days, or even weeks later. 



45 



OPL is, as I pointed out, a general purpose 
on-line language. There exist a number of 
special purpose languages within MAC which 
have roughly the same structure as OPL. One 
of these is COGO (Coordinate Geometry Pro- 
gram) which was developed and is used by 
the M.I.T. Civil Engineering Department. It 
is similar to OPL in that it too uses essen- 
tially the same transfer vector philosophy. 
The functions which may be called have all 
been previously defined and compiled in either 
FORTRAN or MAD. COGO is used by stu- 
dents in the Civil Engineering Department 
for laying out highway interchanges and like 
purposes. The programmer defines points in a 
two dimensional space and asks for them to 
be connected by various curves and straight 
lines. He then interrogates the system about 
the consequences of such connections, e.g., the 
areas determined by various enclosed sur- 
faces. An important property of COGO and 
other programs in the same class is that the 
student needs to know literally nothing about 
the structure of the COGO program itself nor 
about programming in general. STRESS is a 
similar program which deals with the stress 
analysis of structures under loads. 

The principal reason the users of these pro- 
grams need know nothing about programming 
is that both COGO and STRESS are essen- 
tially self teaching. By this I mean that they 
not only respond to the stimuli provided by 
their users in the sense of yielding interme- 
diate results, but give directions for their 
proper use. A particularly strong example of 
such a program is one developed by Hansen 
and Pyle for the design of nuclear reactors. 
This program not only asks for its relevant 
parameters by name e.g. "What fuel do you 
intend to use?"— but also comments on the 
relative appropriateness of the response un- 
der certain condition — e.g. "That's rather 
large"— and gives the user a chance to change 
his mind before going into its calculation 
phase. 

OPL, COGO, and STRESS are each pro- 
grams which, while being on-line, are still 
conventional in the sense that their users 
specify procedures in terms which are gen- 
erally recognizable as program steps and pro- 
duce results which other programs might well 
also produce. A radically different class of 
on-line programs is represented by the "ed" 
and "typset" programs available within the 
MAC system. These are both editing pro- 



grams. They differ from one another mainly 
because the "ed" is designed to process com- 
puter code (in whatever language), while 
"typset" is a general text editor. I will take 
up only the latter. 

Typset operates in either the "input" or the 
"edit" mode. In the former the user types in 
whatever text he pleases, using all characters 
available on either the IBM 1050 or the Tele- 
type keyboard (with the exception of two 
escape characters, one of which is used to 
delete an entire line and the other a single 
character— both may be changed at will). In 
the edit mode the text is edited entirely by 
context. There are no concepts such as line 
numbers nor any others requiring the user to 
remember the appearance of the original text. 
In the edit mode, paragraphs may be inter- 
changed, new text inserted between pairs of 
words or characters, strings of characters de- 
leted, and so on. Text which has been input 
via the typset program is ultimately stored 
on the disk and may be output on any kind of 
paper (e.g. ditto masters) at any time. Since 
it does reside on the disk until intentionally 
deleted therefrom, it may be re-edited repeat- 
edly days, weeks, or months after its original 
composition. 

It seems to me that the "typset" and "ed" 
programs are significant for two separate 
reasons. One is that they provide examples 
of programs which anyone may use to very 
good advantage— anyone, regardless of how 
little or much computer programming he has 
behind him. Even I have been able to turn out 
papers with lines properly centered, left and 
right margins justified, and the proper spac- 
ing between paragraphs. Perhaps of more 
immediate importance is the fact that both 
these programs were written, debugged, and 
put into general use within a few weeks of 
their inception. This, while of credit to their 
authors, certainly also serves as a comment 
on the utility of a time sharing system and 
the on-line program writing and debugging 
facilities it provides to each of its users. 

Now to return to the question of economics 
which I postponed earlier. As already indi- 
cated, I believe the economic issues related to 
the on-line use of computers must be sepa- 
rated according to whether one is speaking 
of small computers operated from their directly 
connected consoles or large time shared com- 
puter systems. The more challenging and 
interesting questions certainly lie in the latter 
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category. Visitors to Project MAC are con- 
stantly asking how much machine time a 
problem they solved on a batch processing sys- 
tem would require on the MAC system to come 
to the same state of solution. I suppose they 
want the answer in terms of numbers of ma- 
chine cycles or some related measure. Perhaps 
these questions can be answered with preci- 
sion in some cases. Whether such answers 
would be impressive would depend, of course, 
on the efficiency of the batch processing sys- 
tem with which the MAC system is being 
compared. Batch processing also entails over- 
head. However, I do not believe such questions 
to be very meaningful— no more so, for ex- 
ample, than asking for the average floating 
point add time of a machine like the STRETCH 
leads to any insight into the overall effective- 
ness of such a machine in relation to specific 
problem classes. It must be remembered that 
economics deals with the allocation of scarce 
resources. To consider the number of machine 
cycles required to solve a particular problem 
to be the principal measure of effectiveness of 
a system assumes that the scarce resource to 
be conserved is machine time. It is not. In any 
case, one would probably not take the same 
code as that which was generated for the 
batch processor and run it in the time shared 
environment. In the batch processing environ- 
ment the programmer knew that access to the 
machine was limited to a few shots a day. 
He wrote his code in anticipation of every 
conceivable event, asked for large dumps, 



interleaved the operationally significant por- 
tions of his program with elaborate diagnos- 
tics, and so on. None of these precautionary 
measures are necessary with on-line oper- 
ation. Programs are therefore shorter and run 
correspondingly faster. 

The scarce resource which is being con- 
served in the on-line mode of computer oper- 
ation is the energy and time of people. Our 
experience with Project MAC has taught us 
that the exploratory use of computers, such 
as has by now become habitual with us, serves 
to amplify the effectiveness of people in dra- 
matically visible ways. Just as the introduc- 
tion of the computer itself made possible 
attacks on problems which simply could not 
be attempted earlier, so we find that our mode 
of operation encourages people to search their 
own problems more deeply, to be dissatisfied 
with sloppy solutions which might have 
passed earlier because "after all, they work". 
In short, we are beginning to see the use of 
the computer as a real and significant assist- 
ant to human beings engaged in problem 
solving. Who is to say what economic values 
accrue to an institution when creative people 
complete their tasks in days instead of weeks, 
or when a problem which could previously not 
be attacked at all is now solved? 
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On-Line CRT Displays: 
User Technology and Software 



INTRODUCTION 

The increasing application of on-line data 
processing systems has accelerated interest in 
visual display devices for augmenting the 
interaction of man and machine. To date, this 
technology had been primarily developed for 
the military, where the requirements of air 
defense stimulated the first application of in- 
dividual display console devices for the Semi- 
Automatic Ground Environment (SAGE) and 
the Naval Tactical Data System (NTDS). 

Visual displays have been with us from the 
earliest days of computing. For example, one 
of the first display devices associated with a 
computer system was the cathode-ray tube 
(CRT) display. One of these displays was 
available in 1953 on the ILLIAC (University 
of Illinois) computer where two tubes were 
driven in parallel. One CRT was mounted for 
visual observation, the second was associated 
with a camera capable of photographing the 
computer generated display. The computer 
controlled the film advance. While the pri- 
mary use of this display was the rapid gener- 
ation of graphic information, another use was 
on-line monitoring of the progress of a calcu- 
lation. By appropriate displays, a programmer 
could detect programming errors, or, during 
production runs, make better initial guesses 
for iterative procedures or parameter studies. 
Subsequently, such systems became available 
commercially as, for example, peripheral de- 
vices to the IBM 704 computer system. 
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This paper explores the current state of the 
art of CRT displays and discusses, from the 
user's point of view, potential applications and 
the computer programming software neces- 
sary to implement these systems. 

CRT DISPLAY CONSOLE 
CHARACTERISTICS 

From many points of view, all of the fol- 
lowing are on-line display devices : typewriter, 
plotter, printer, closed circuit TV, document 
viewers, CRT consoles, and tote boards. 

This paper discusses the CRT display con- 
sole which meets three on-line capability cri- 
teria. First, it is directly tieable to a data 
processing system. Second, it has ability to 
initiate messages or control signals from a 
data entry keyboard or switches for transmis- 
sion to the computer. Finally it has ability to 
receive digital messages or control signals 
from the computer and display them to the 
operator or viewer. 

Typical Features 

The CRT display console is a desk type unit 
with varying combinations of features and 
capabilities for information entry and dis- 
play. The primary entry devices are the alpha- 
numeric keyboard and switch action keys. The 
output is typically produced via a CRT and 
status indicators. Aids to data entry and 
output observations are provided. Table 1 
summarizes these features, and includes as- 
sociated check points which allow a specific 
device to be evaluated. Figure 1 is a concep- 
tual drawing of a display console identifying 
these generic features. An important distinc- 
tion is made between the marker, light pen 
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and cursor, each representing a unique capa- 
bility for data entry. 

The marker defines a position on the face 
of the CRT where a character appears when 
selected from the keyboard. This advances 
across the face of the display as characters 
are successively entered. 

The light pen is a photoelectric device which 
can be aimed at any position on the CRT. 
When the light pen is activated, and the point 
on the CRT at which it is aimed emits light, 
a message is generated to the computer iden- 
tifying the location of that point. 

The cursor is a feature which permits the 
location of any point on the CRT, independent 
of the presence of light. 

These three capabilities can be satisfied un- 
der software control and in conjunction with 
several variable function keys. It is also pos- 
sible to meet these requirements with hard- 
ware features in several ways. For example, 
the "position-pencil control" of the IBM 7460 
Special Image Processing System encompasses 
the features of both the light pen and cursor. 




CRT 



STATUS & ERROR 
INDICATORS 



LIGHT PEN/ 
CURSOR CONTROL 



FUNCTION KEYS 



FIGURE 1 

TYPICAL CRT DISPLAY CONSOLE 



TABLE 1 

CRT DISPLAY CONSOLE FEATURES 





Check Points 


Associated Features 
for Data Entry 


Associated Features 
for Output Observation 


Alphanumeric Keyboard 


Number of characters 
Availability of special 
Symbol s 


Marker indicating on CRT 
point of character entry 




Switch Act ion Keys 


Number of keys under 

program control 

(Variable Function Keys] 
Number of keys under 

hardware control 

(Fixed Function Keys) 


Lights associated with 
keys for indicating: 

- key selected 

- allowable key selection 




Cathode Ray Tube 


Size of screen 
Number of characters 

that can be displayed 
Position accuracy 
Ability to draw vectors 
Number of character sizes 


Light pen for point selection 

on CRT 
Cursor for locating position 


Selected output features: 
-blinking of characters 
-intensity variation 
-character size variation 
-character rotations 

Mix analog and/or video 
information with computer 
generated digital information 

Color presentation 


Status Indicators 


Number of lights under 
program control 

Number of lights under 
hardware control 




Abil ity to bl ink 1 ight 

Ability to control audible alarm 
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A summary of a number of commercially 
available display devices and features is given 
in Table 2. 

Operations 

The utility of the features associated with 
on-line display consoles is measured in terms 
of each application. It is possible, however, 
to define operations common to many applica- 
tions and assess the need for the capabilities 
identified in Table 2. Such a list of common 
operations includes : initiate an action or pro- 
gram in the system; send a message to one 
or more other console stations or the com- 
puter; request a hard copy output product; 
view an output generated for the CRT dis- 
play; perform a logical operation at the con- 
sole by a man/machine oriented procedure 
(e.g., data base query or special computa- 
tions) ; control access and viewing of back- 
ground projections; and generate visual dis- 
plays for storage and later viewing, specifically 
with reference to background projections. 

The console hardware capabilities or fea- 
tures required for performance of these oper- 
ator functions are shown in Table 3. 

Consider the first item. To initiate an ac- 
tion, a key must be pressed. This is usually 
one of the variable function keys. For illus- 



AVAILABLE MODES 
(CHOOSE ONE) 

REAL TIME, PROGRAM A 
REAL TIME, PROGRAM B 
SPECIAL RUN 
COMPILE RUN 

BATCH PROCESSING 

TIME SHARED, MULTI USERS 
HARDWARE SYSTEM DIAGNOSTICS 
SOFTWARE SYSTEM MAINTENANCE 



FIGURE 2 

LIST OF CHOICES: "MODE SELECTION" 



tration, let such a key be labeled "Mode Selec- 
tion^" The pressing of this key may cause, 
under program control, the display of a list 
of alternatives as shown in Figure 2 . The 
desired mode is then selected by pointing the 
light pen at the appropriate asterisk, say 
opposite HARDWARE SYSTEM DIAGNOS- 



TABLE 2 

SUMMARY OF ON-LINE CRT DISPLAY CONSOLE CHARACTERISTICS 
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Data Displays: DD10 
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Up to 64 displays per 
control unit at $25K 
extra 


Data Display: DD80 
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Has associated film 
recording capability 


General Dynamics: SC 1090 
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Additional options 
avai lable 


Bunker Ramo: BR85 
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Raytheon: DIDS500 
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Joystick provides 
equivalent of light pen 


ITT: Information Display Console 
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Includes color 
presentat ion 
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Buffer memory optional 
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TABLE 3 

RELATIONSHIP OF CONSOLE FEATURES TO GENERIC MAN/MACHINE OPERATIONS 





Console Features 


Function 
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Initiate Action of Program 


X 
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X 
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Send a Message to Other Consoles or 
to the Computer 


X 
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X" 
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Request a Hard Copy Output Product 
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X«' 
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View on Output 
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Perform a Logical Operation 


X 






X 


X 


X 




X 








Control Background Projection 
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Generate Visual Displays for Storage 
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X* 
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*Can be implemented hardware or software 

TICS. It may be that the item selected requires 
further detailing. Hence, a second display- 
automatically appears forcing the operator to 
make a further choice, as in Figure 3 . Actions 
for manipulating the "list" display require 
only the variable function keys, an alpha- 
numeric display capability, and the light pen 
for selection. 

The selection of CORE MEMORY from the 
list in Figure 3 may force the format of Fig- 
ure 4 on the CRT, requiring the indicated 
input from the operator. The symbol " " 
represents the "marker" and indicates the 
first entry point when the alphanumeric key- 
board is used for data entry. This marker 
moves either under hardware or software 
control to the next succeeding underline as 
each character is entered. 

For this latter action of handling "format" 
displays, the marker and data entry keyboard 
is required, completing the explanation of fea- 
tures needed to accomplish the first function 
of Table 3. 

APPLICATIONS 
The on-line CRT display console is rapidly 
reaching a degree of acceptance in the commer- 
cial environment as evidenced by the availabil- 
ity of display devices as standard peripherals 
to many of the newly announced computer 
systems. The development of application areas 
and user techniques has, however, lagged so 



AVAILABLE SYSTEM DIAGNOSTICS 
(CHOOSE ONE) 

CORE MEMORY 

* TAPES, CHANNEL A 
TAPES, CHANNEL B 

DRUM 1 
DRUM 2 

DISC I 
DISC 2 

CARD READER 

* CARD PUNCH 
PRINTER 1 
PRINTER 2 



FIGURE 3 

LIST OF CHOICES: "SYSTEM DIAGNOSTICS' 



CORE MEMORY DIAGNOSTICS 

TEST LOCATION: 

i _ _ _ TO _ _ 

BIT PATTERN (OCTAL): 

(IF NONE STATED, STANDARD IS USED) 



FIGURE 4 

FORAAAT FOR ENTERING REQUESTED INFORMATION 
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that there is still considerable potential user 
caution and hesitancy. 

Three major application areas have devel- 
oped : demand query, monitoring, and analysis. 
In the first, a service is provided to a person 
who wishes immediate information that must 
be extracted from a large mass of data and may 
require some rudimentary analysis or trans- 
formation before it is useful to him. Examples 
are: a manufacturing planner wants to know 
the status of a release order for certain parts ; 



an investor wants to know the status of his 
account with his broker; and a policy holder 
wants to know how much he can borrow on 
his life insurance policy. 

Included as candidate applications for de- 
mand query are: reservations (travel, hotel, 
etc.), merchandising inventory, manufactur- 
ing inventory, manufacturing and production 
control, insurance policy information, credit 
information, bank or brokerage customers ac- 
count information, real estate information, 



TABLE 4 

DISPLAY CONSOLE OPERATING CHARACTERISTICS FOR SELECTED APPLICATIONS 

Characteristics 
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Reservations (travel, hotel, etc.) 
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Manufacturing and Production Control 
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stock quotation, management control, com- 
puter system status, and patent or law prece- 
dent search. 

For a demand query, the user is interacting 
with a display in a very active manner. The 
user has an objective in mind. He makes an 
inquiry of a general nature; a display is pre- 
sented. Based upon this newly acquired infor- 
mation, the user jnay particularize his inquiry. 
A new presentation gives him additional infor- 
mation. The sequence continues until the user 
has all the information required to take some 
action. 

For display monitoring, the user does not 
interact at all with the display. He is entirely 
passive. The presentation made by the display 
may change at a slow or rapid rate ; the user 
observes it and obtains the information neces- 
sary for action. Typical applications include: 
computer - monitored tests, process control, 
stock status, hospital operation, and simula- 
tion. 

In the third application area, the display 
console is used as an analytical tool to fulfill 
the basic task itself. Here the man and 
machine operate in conjunction. Examples 
include: information retrieval, input data 
screening and updating, tape file editing, 
on-line programming or debugging via re- 
mote console, computer aided drafting, war- 
gaming, and teaching machines. 



The foregoing applications may be analyzed 
in terms of certain characteristics. First, the 
number of stations required. For example, 
airline reservations require many stations, 
each agent having an individual set. On the 
other hand, the director of a computer moni- 
tored test requires only one station. Next, 
input and output can differ completely from 
one application to another with respect to 
quantity, degree of encoding, number of sym- 
bols, whether it is pictorial, etc. Also, the 
degree of interaction between the user and his 
(computer-controlled) display differs in speed 
of required response and in the way that the 
responsibility for analysis is divided between 
the man and the computer. 

Some characteristics for the applications 
listed above are shown in Table 4 . General 
conclusions for each class of applications are 
given in Table 5. 

APPLICATION EXAMPLE: QUERY 
One of the more important uses of the on- 
line console is to ask questions of the data 
processing system. This process can be as 
simple as pressing a key and inserting an 
appropriate five character code to obtain a 
bank balance, as with demand query. Or it 
may be a complicated logical statement whose 
rules of formulation may be as complicated as 



TABLE 5 

SUMMARY OF OPERATING CHARACTERISTICS FOR SELECTED APPLICATIONS 



Appl icat ion Class 


Number of Stations 


Output 


Input 


Man/ Computer 
Interaction 


Demand Query 


Many 


A/N; 

Varying Amount 


Highly 
Encoded 


Slow; Analysis 
by Man 


Monitor 


Few 


A/N & Vector; 
Mostly large 
Quantity 


Encoded 


Fast; Analysis 
by Machine 


Analysis 


Few 


A/N & Vector; 
Large Quantity 


M i xed ; 

Coded & Message 


Slow; Analysis 
divided by Man 
and Machine 
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the search process which obtains the answer, 
as in interrogation for information retrieval. 
Consider, for example, the conventional off- 
line procedure for interrogation as shown in 
Figure 5 . Here, the user may be as much as 
nine steps removed from the solution of his 
problem. Beyond this limitation the conven- 
tional process would require, at some stage of 
operation, adherence to very formal rules. The 
first of these rules is concerned with spelling- 
abbreviations, plurals, possessives, may be 
illegal. Next is the use of special words- 
synonyms may be prohibited, special codes 
may be required. Then there is punctuation- 
queries may have to be marked off and seg- 
mented. In short, a special syntax, dictionary 



and code book may be required for use of the 
system. 

The on-line display console facilitates the 
process of query by eliminating the interme- 
diaries controlling input (and hence errors) 
and automates the dictionary and syntax rules. 

Consider, for example, an on-line system 
which permits query of a data base consisting 
of information about the stock market. We 
assume that a satisfactory set of variable 
function keys consists of keys for: MARKETS, 
INDEXES, INDUSTRY CLASSES, SUM- 
MARY LIST, SELECTION CRITERIA, DE- 
TAIL LIST, GEOGRAPHIC, PLOT, and 
TIME. 



FILL OUT REQUEST 
FORM USING 
APPLICATION-ORIENTED 
LANGUAGE 


CONSUMER 

MESSENGER 

DISPATCHER 

INFORMATION 
SPECIALIST 

KEY PUNCH 
OPERATIONS 


STUDY RESULTS 
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SUBMIT TO 
PROCESSING CENTER 




SUBMIT TO 
CONSUMER 


1 


J 


t 


RECEIVE MESSAGE 
AND LOG 


LOG OUTPUT 
AND DISPATCH 


1 


r 


i 


, 


TRANSLATE TO 
COMPUTER-ORIENTED 
LANGUAGE AND 
FORMAT 




OUTPUT CONTROL 


I 


1 


1 


1 


KEY PUNCH AND 
VERIFY 




1 




RUN ON 
COMPUTER 











FIGURE 5 

CONVENTIONAL PROCEDURE IN REQUEST FULFILLMENT 
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NEW YORK 

AMERICAN 

OVER THE COUNTER 

MUTUAL FUNDS 

BONDS 

COMMODITIES 

LOCAL AREAS 



MfotjStTS^ 


— 


SUMMARY 
LIST 


INDUSTRY 
CLASSES 


TIME 


DETAIL 
LIST 


SELECTION 
CRITERIA 


INDEXES 


PLOT 



FIGURE 6 

LIST DISPLAY OF MARKETS 



INDUSTRY CLASSES 




TRANSPORTATION 


FUEL 


METALS 


DRUGS 


UTILITY 


PLASTICS 


FOOD 


BUILDING 


COMMUNICATION 


ADVERTISING 


ELECTRONICS 


TEXTILE 


BANKING 


SERVICES 


INSURANCE 


TOBACCO 



MARKETS 


GEOGRAPHY 


SUMMARY 
LIST 


rNQUSTRV^^ 


TIME 


DETAIL 
LIST 


SELECTION 
CRITERIA 


INDEXES 


PLOT 



FIGURE 7 
LIST DISPLAY OF INDUSTRY CLASSES 



TRANSPORTATION 



AIRLINE 
AUTOMOTIVE 
RAILROADS 
BUS LINES 
TRUCKING 
SHIP LINES 



MARKETS 


GEOGRAPHY 


SUMMARY 
LIST 


INOUSJRY^ 
CLASSES 


TIME 


DETAIL 
LIST 


SELECTION 
CRITERIA 


INDEXES 


PLOT 



The following statement is entered through 
the keyboard : 

List all automobile and airline stocks 
on the New York Stock Exchange 
which have a yield of at least 2 % in 
1964. 

To start the process, the MARKETS key is 
pressed. The display shown in Figure 6 ap- 
pears; from this list display the item NEW 
YORK is selected. Next, the INDUSTRY 
CLASSES key is chosen, which results in a 
display of INDUSTRY CLASSES as shown 
in Figure 7 . The category TRANSPORTA- 
TION is selected, which is automatically fol- 
lowed by a breakout of this item as shown in 
Figure 8 . From the latter list, items AUTO- 
MOBILE and AIRLINE are chosen. 

When the SELECTION CRITERIA key is 
pressed, the format display of Figure 9 is pre- 
sented. This display permits the selection of 
ranges for the indicated criteria, where the 
left and right locations correspond to the 
lower and upper bounds. The number two is 
entered as a lower bound (leaving the upper 
bound blank, which by convention indicates 
infinity). 

The TIME key is next selected, and the 
desired calendar period is entered. Finally, 
the SUMMARY LIST key is chosen and the 
query entry completed. The resulting output 



SELECTION CRITERIA 

LOW 

HIGH _ 

HIGH/LOW _ 

RANGE _ 

* TRADED _ 

YIELD _ 

DIV. _ 
P/E RT. 
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INDUSTRY 
CLASSES 


TIME 
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LIST 


SEbECTIOKr 
CRJJElSk 


INDEXES 


PLOT 



FIGURE 8 

LIST DISPLAY OF TRANSPORTATION 



FIGURE 9 

FORMAT DISPLAY OF EARNING RATIO 
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from this query, when retrieved, may appear 
as shown in Figure 1 . 

SOFTWARE REQUIREMENTS 
Hardware Environment 

The extent of software depends upon the 
hardware environment. Figure 11 represents 
a very general system where the display sub- 
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FIGURE 
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FINAL QUERY 


OUTPUT 



system functions are specifically identified. In 
particular, the display subsystem controller is 
shown to have the function of: message rout- 
ing, data buffer, display regeneration, and 
character generation. 

The latter two functions are generally part 
of each console hardware unit. Then the dis- 
play regeneration is performed from a buffer 
memory associated with the console. 

If the display subsystem controller is a com- 
puter, then it may have direct access to the 
data base as shown by the dotted line. The 
controller is then capable of performing much 
of the man/machine communication. In the 
following text it is assumed that such is true. 

Software Design Parameters 

The interactions between man and machine 
are spread over relatively long periods of 
time, and are asynchronous with respect to 
each of the users. Hence, if reasonable re- 
sponse times are to be met, access must be 
provided to programs, pre-stored displays and 
data on a random basis. Because of the ex- 
pected time sharing of the central processor 
between multi-stations for intermittent serv- 
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icing, console "history tables" reflecting user 
transactions to the current time must be 
maintained. In addition, since unpredictable 
time lapses occur due to intermittent human 
responses, the "position" of a program in a 
particular procedure must also be maintained. 

Effectively, the program must wait (or do 
something else) whenever a display is pre- 
sented to the operator. As the operator enters 
data (if required), the computer must momen- 
tarily return control and monitor each entry. 
After the entries for a single display are com- 
pleted, an appropriate "end of message" ini- 
tiates the next logical step. At the end of the 
final step, a complete and meaningful message 
or direction is the basis for the computer's 
independent determination of what is to be 
done. It is thus possible to generate directions 
continually and to have the computer respond 
to them on an overlapping basis. 

It is possible to separate the application 
oriented functions from those that are general 
purpose, and to apply to most on-line display 
system applications and processes. The divi- 
sion is made between the processes required 
in generating the message and the actual pro- 
cedures for executing the action that may be 
called. The former concerns the mechanics of 
handling displays and composing messages ; 
the latter is concerned with actual file han- 
dling, retrieval, processing, summarizing and 
formating. In this discussion, attention is re- 
stricted to the first aspect, the general purpose 
processes. 

The objectives for the programming system 
design are four : first, to provide general ca- 
pability and flexibility so that virtually all 
applications can be accommodated. 

Second, to standardize techniques and pro- 
cedures so that individual program segments 
or subroutines can be shared by as many func- 
tions as possible. 

Third, to maintain order among contending 
users for the same files. 

Fourth, to service each console as if its 
operator is the only user making demands 
on the processor. 

Based on the above discussion, the program- 
ming system must include at least the follow- 
ing programs. 

Display Subsystem Executive Control. This pro- 
gram performs the basic scanning, sequenc- 
ing and queue control for servicing the on-line 
devices. In addition, it links to the master 



executive control which may be supervising 
the total processing. 

Function Monitor. This program maintains the 
history tables and establishes the action se- 
quences to be carried out as a function of the 
keys that are pressed. 

Utility Program Package. This is a collection of 
service routines used primarily by the func- 
tion monitor and executive control. The avail- 
ability of these general purpose programs pre- 
cludes the recoding of common functions. 

Implementation Language. This is a language 
used by the application programmer in writ- 
ing his program and is operated upon by the 
function monitor. The system must provide 
the programmer with the ability to express 
his program in both the symbolic language 
of the computer where each command gen- 
erates one machine instruction and in higher 
order languages where each command gen- 
erates many machine instructions. To be effec- 
tive, the higher order language must be 
powerful enough to express the application 
problem in terms of the man/machine en- 
vironment, usable with a modest amount of 
training, and readily expandable so that new 
commands and functions can be added. 

A system such as this implies that applica- 
tion programmers must conform to certain 
coding restrictions and procedures so that 
all the possible programs can be accommo- 
dated. While this may seem a disadvantage, 
it is, in fact, helpful since it simplifies the 
programming (because of the existence of 
service routines). It also simplifies the im- 
plementation of new applications, since they 
must fit within the logical framework set 
forth by the system. 

The importance of the second point cannot 
be over-emphasized. Without a well defined 
organizational and procedural philosophy, the 
programming design and implementation of 
the individual application can become a major 
undertaking. 

Display Subsystem Executive Control 

Table 6 presents the programming and stor- 
age requirements for a typical display sub- 
system. The real time requirements associated 
with on-line displays present a problem of 
priority interrupt handling and servicing. 
Hence, an executive system must be designed 
to be responsive to these requirements. Such 
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TABLE 6 

PROGRAMMING REQUIREMENTS 
FOR A DISPLAY SUBSYSTEM 
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a program is equipment dependent in the 
sense that many hardware/software trade- 
offs are possible. 

The basic requirement of the display sub- 
system is control of a great number of input/ 
outputs including ; scanning the input lines for 
messages, refreshing the CRT's, accessing 
programs, displays and data from auxiliary 
memory, communicating with other processors 
that may be in the system, and maintaining 
timing responses for special purpose on-line 
character generating equipment. 

Typical timing requirements range from re- 
freshing the CRT within 20-25 ms periods, 
to scanning of inputs from the console key- 
boards every 200 ms. Unless certain hardware 
features are available, such as automatic in- 
terrupts and input/output buffering, the pro- 
grams have to take these into account. Assum- 
ing no dependence on hardware, the executive 
program must maintain continuous cognizance 
and control over the input/output. This is done 
by the basic control loop shown by the dotted 
lines in Figure 12. Each of the five indicated 
functions could potentially generate a process- 
ing task as the cycle is traversed. For example, 
the tasks associated with scanning the input 
message lines is shown in Figure 13. 
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To meet real time requirements, this loop 
must be passed at a rate which insures return 
to the task which has the tightest timing 
constraint within a specified amount of time. 
This time is called the "basic cycle time." 
Thus, if the CRT refreshment is the critical 
task, then the basic control loop must return 
to that task within a basic cycle time. 

There is also the further implication that 
the processing requirements for each of the 
five identified functions must be completed 
within a time which does not compromise 
the total cycle time. 

There are three ways to do this. The first 
is to allow processing to proceed in increments 
of the basic cycle time so that temporary re- 
turn to the cycle is permitted after each such 
segment. This leads to difficulties of recur- 
sive entries into the various processing tasks. 

The second way is to spot-place a particular 
task in more than one position in the loop. 



Thus, for example, the "refresh CRT" might 
be placed in every other position in the loop 
if the other functions have a period which is 
very much larger than that of the CRT re- 
fresh cycle. 

The third way is to permit only a minimum 
of processing as each of the tasks is reached, 
and to place in a queue those functions not 
completed. This queue is then processed dur- 
ing the residual time which is left over during 
every cycle. This is shown in Figure 12 by 
the box which is part of the loop indicated by 
the heavy lines. It is, of course, necessary that 
the residual be non-zero enough of the time 
if any processing is to occur. 

The following comments are presented con- 
cerning the implementation of the executive 
control with respect to the presence or ab- 
sence of the indicated hardware features. 

If neither external interrupt nor a real time 
clock is available, the tasks associated with 
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each of the control loop functions, and all 
other calculations, must be programmed in 
segments so that each segment permits return 
to the control loop and maintains the timing. 

If a clock is available, the executive can 
preset it at the beginning of each cycle so that 
it interrupts the processing of the queue at 
the proper time. 

If external interrupts are available, the 
function of the basic control loop has been 
absorbed by the hardware and a minimum 
executive function is needed. Consoles are 
then serviced on demand. 

Function Monitor and Implementation Language 

The function monitor is a specially designed 
program to facilitate responses to the con- 
sole's variable function keys. Although not all 
consoles have a set of keys of this type, a 
general purpose console has such a set.* These 
keys are characterized by the fact that their 
labels, and also their identifying codes, can be 
changed by the operator to suit the application. 

The process of entering information into 
the computer to make a request has been dis- 
cussed in detail in the previous section. Differ- 
ent applications require different displays and 
different sequences of presentation, and it is 
advantageous to design a scheme which is 
not application dependent, so that the user 
can design his own data entry scheme and 
query language. 

The function monitor operates on a very 
special implementor's language oriented to 
display manipulation. When one of the func- 
tion keys mentioned above is depressed, the 
executive control recognizes this and passes 
control to the function monitor. It is the ease 
with which the implementor can specify and 
modify this list of statements which makes 
the function monitor so valuable. To illustrate 
the capability of the language, some of the 
possible statements are now given. 

The first is : turn specified console lights on 
(off)— the lights are specified in parameter 
words following the instruction. 

Another is : display the following characters 
on the CRT— the characters along with their 
location coordinates are listed following the 
instruction. 



* These keys can be implemented by hardware or soft- 
ware. For example, if keys are unavailable or limited, 
they can be simulated on the CRT itself and the light 
pen can be used to "press" the keys. 



Others are: locate a display in auxiliary 
storage and present it on the CRT— the identi- 
fication of the display follows the instruction; 
clear a specified buffer— the buffer area may 
be either pre-established or specified in the 
words following the instruction ; and enter the 
specified characters in the buffer— the charac- 
ters are listed following the instruction. 

Finally, there is: process the "list" display 
—special codes (specified by the query lan- 
guage) are extracted from the list display 
as dictated by the selections of the operator 
and are placed in the buffer; and process the 
"format" display— the parameters entered by 
the operator are extracted from the format 
display and stored in the buffer. 

A more sophisticated language can be de- 
signed to cover more applications. The above 
language, however, is indicative (along with 
the function monitor) of what is necessary 
to service the kinds of retrieval requests 
mentioned earlier. 

Utility Programs 

Utility or service programs extend the hard- 
ware so that user functions become available 
to the application programmer without his 
concern for programming them. This soft- 
ware is primarily concerned with making it 
easier for the entry of alphanumeric infor- 
mation on to the CRT, expeditiously. Also in- 
cluded are useful functions for data handling, 
control of displays, system control, and the 
detection and setting of status and error in- 
dicators. 

CONCLUSION 

In the past, on-line display devices were 
primarily of interest to the military. Now, 
the commercial market is becoming a serious 
user. Evidence of this is shown by the increas- 
ing number of demand query reservation and 
quotation systems and time sharing systems 
such as Project MAC. These applications are 
stimulated by the current trend to on-line and 
real time data processing systems. 

The many possible applications of display 
devices suggest a need for general purpose 
software to assist the programmer in design- 
ing and implementing man/machine proce- 
dures. 

This paper has identified the generic fea- 
tures common to on-line CRT displays which 
form the basis for software responsive to 
these features. 
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INTRODUCTION 

On-line control is the basis for a broad 
spectrum of significant work being performed 
in a wide variety of applications areas. The 
"least difficult" applications have been attack- 
ed first— and successfully. By "least difficult" 
is meant those applications requiring rela- 
tively slow response times (chemical proces- 
ses requiring 5-10 minute control cycles— 1 or 
2 human reactions— data logging). Conven- 
tional general purpose computers designed 
primarily for batch-processing have been the 
nuclei of these initial systems. The problems 
encountered have made the phrase "program 
around it" commonplace. 

The "more difficult" on-line applications re- 
main to be done. The demands implicit in the 
process, or simply the cost feasibility, require 
that on-line systems, particularly the central 
computer, be designed so that "programming 
around" a deficiency is not necessary. This is 
not for the convenience of the programmer 
since he is professionally committed to the 
performance of different tasks, but because 
the phrase implies the substitution of a se- 
quence of program steps requiring a measur- 
able amount of time for hardware capable of 
responding in an instruction time. These 
"more difficult" applications cannot tolerate 
relacement of hardware by programming be- 
cause the required response times are so fast 
that programming implementation is not feas- 
ible. 

Basically, in all on-line control systems, the 
central computer acts as a "transponder" (i.e., 
the computer performs some calculations and 



initiates passes on the basis of an incoming 
signal). Some examples of incoming signals 
are time sharing customer stations, clocks, 
emergency alarms, and management inquiries. 
To such incoming signals, the computer must 
respond rapidly and reliably. How well the 
computer is able to do this generally deter- 
mines the maximum capability of the on-line 
system. A necessary ingredient in the respon- 
sive ability of the on-line system is the inclu- 
sion of a powerful and flexible priority inter- 
rupt system. 

PRIORITY INTERRUPT SYSTEMS 
Priority interrupt, as a concept, has been 
with us for a long time. Interrupt experiments 
were conducted on systems as early as the 
Whirlwind I. Subsequent command and con- 
trol systems have incorporated interrupt 
techniques which provided the necessary capa- 
bility for the not too demanding "least diffi- 
cult" problems. In the last three years, how- 
ever, specific interrupt techniques have been 
developed to satisfy the "more difficult" on- 
line applications. This development coincides 
with the appearance of production line real 
time computers. 

To measure the effectiveness of a priority 
interrupt system, certain criteria must be 
established : 

Reaction Time: this is the time between the 
occurrence of a signal (or request) external 
to the central computer and the commence- 
ment of execution of the first useful instruc- 
tion requested by the external signal. 
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Overhead: is the difference between the total 
time necessary to completely process the in- 
coming request and the execution time of all 
useful instructions. 

Optimum Priority Response: is the ability of the 
central computer to correctly react to incom- 
ing priority requests. If the "most important" 
instruction is not being executed at a given 
instant of time (as determined by the priority 
status of the request lines), then the priority 
response of the central computer is said to be 
sub-optimum. 

System Saturation: occurs when the on-line sys- 
tem cannot respond quickly enough to all of 
the requests. The system is underdesigned if 
this state exists. 

TYPES OF PRIORITY INTERRUPT 

SYSTEMS 
At least three types of priority interrupt 
systems are in general use today. These are 
the search ring method, the single-level indi- 
cator method, and the matrix control method. 

Search Ring Method 

The search ring method is implemented by 
use of an n position electronic stepping 
counter which continually scans n interrupt 
lines. The highest priority lines are scanned 
first so that, if two requests are received 
simultaneously, the higher priority line is 
recognized. The counter associated with the 
position of this interrupt is then transmitted 
to the central computer to be used in forming 
the address of the first instruction to be exe- 
cuted. The program counter is automatically 
saved and restored at the end of interrupt 
processing. 

This method has poor reaction time since if 
any interrupt is now being processed, the 
computer is "locked out" from all other inter- 
rupts. In the worst case, the response time 
can be as long as the longest interrupt serv- 
icing routine in the system. Overhead, how- 
ever, is not excessive, since the program 
counter is saved and restored. True, priority 
response is not present since the simple scan- 
ning technique prohibits a high priority inter- 
rupt from being recognized while one of lower 
priority is being processed. This method is 
thus said to be single level as opposed to true 
priority. Another disadvantage of the search 
ring method is its capacity. As n increases, 
the time to scan all lines increases. If n is 



large enough, either faster (and more expen- 
sive) components must be used or the scan- 
ning cycle increases, lengthening the reaction 
time even further. 

Single Level Indicator Method 

The single level indicator method is the 
most common (and least expensive) method 
in use on existing computers. Essentially all 
interrupt lines develop an "OR" output which 
serves as the interrupt request signal to the 
central computer. At the completion of the 
current instruction, the program counter is 
stored and an interrupt processing subroutine 
is entered ( See Figure 1 ). This subroutine 
tests each interrupt line in sequence to deter- 
mine which request caused the interrupt. 
Either by program or automatically, the in- 
terrupt line recognized is reset and program 
control is transferred to the correct routine. 

The response time and overhead for this 
method are both very high since, after the 
interrupt request line is activated, a signifi- 
cant number of program steps must be exe- 
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cuted before the central computer begins to 
obey the request. While the highest priority- 
requests will be tested first, the high overhead 
may make the lower priority interrupts in- 
effective. This method is also single level since 
no interrupt can be recognized while one is 
being processed. 

The combination of slow response time and 
high overhead plus the lack of true priority 
response makes system saturation a possi- 
bility before the capacity of the central com- 
puter has reached an economic level. Consider 
an m microsecond computer having two inter- 
rupts occurring every 500 m time intervals. 
The overhead on each interrupt processing 
would conservatively be 20 m. The non-useful 
computing time just to recognize these inter- 
rupts would take 8 % of the computer's capac- 
ity. If more interrupts of lower priority are 
added (with their correspondingly high over- 
head) system saturation is very likely to 
occur. 

Matrix Control Method 

The third method, the matrix control 
method, provides two flip-flops for each inter- 
rupt line to be recognized. These flip-flops 



provide the necessary memory to determine 
the current status of the line. Three states are 
used, as shown in Table 1 . 

Table 1 . States of Matrix Control Method 



State 



Condition 



No interrupt has been requested on 
this line. 

An interrupt has been requested, but 
has not been recognized by the com- 
puter. 

The requested interrupt has been 
recognized by the computer, but has 
not been completed. 



Each interrupt line (or level) is positioned 
into a matrix based on the order of priority— 
the highest priority being closest to the out- 
put, while the lowest priority is the farthest 
away ( See Figure 2 ). An interrupt request 
being received at a given level automatically 
causes the level to shift from state 1 to state 
2. If no higher priority level is present in 
states 2 or 3, the matrix permits the interrupt 
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request line to be activated to the central com- 
puter. At the same time, an address unique 
to the requesting level (determined by diode 
selection) is supplied to the computer. At the 
completion of the present instruction, the 
computer transfers control to the memory- 
location determined by the provided address. 
At this point the program counter is pre- 
served and a signal is sent to the priority 
interrupt system to change the state of the 
highest priority level in state 2 to state 3 (by 
design, the requesting interrupt level). At the 
completion of the desired routine, a unique 
instruction returns control to the point of 
departure, simultaneously signaling the prior- 
ity interrupt system to change the highest 
priority level, at present in state 3 to state 1. 

The matrix control method provides both a 
short reaction time and low overhead. Every 
interrupt request is obeyed immediately pro- 
vided no higher priority request is in execu- 
tion. A favorably low overhead is achieved 
since no program time is used to transfer to 
and return from the desired routine. The big- 
gest advantage of this method, however, is a 
near optimum priority response. The most 
important instruction is being, or is about to 
be, executed at any instant of time. When the 
required routine for any interrupt level is 
completed, the matrix control method ensures 
that the next routine to be executed will have 
the highest existing priority regardless of 
how many lower priority requests remain only 
partially completed. 

The effect of the matrix control method 
may be achieved without the structure de- 
scribed here. The required elements are a) 
memory for each interrupt level, b) a hard- 
ware priority structure, and c) central com- 
puter communication to inform the priority 
interrupt system of a change in state. To con- 
serve cost, interrupt levels have been "shared" 
by a number of interrupt lines in some sys- 
tems. Since the lines must not interact, the 
on-line systems designer must take this ap- 
proach with caution. 

CURRENT-STATUS PRESERVATION 
vs. OVERHEAD 

So far, the problem of preserving machine 
registers (other than the program counter) 
has not been mentioned. This problem is dis- 
crete and exists regardless of the interrupt 
recognition methods mentioned previously. If 



the routine executed in response to an inter- 
rupt request uses (or destroys) any of the 
machine registers (such as the accumulator, 
index registers, overflow indicator, etc.), the 
contents prior to use must be preserved and 
restored after completion. The problem is 
likely to become more complicated since com- 
puters are being designed with more and 
more machine registers for greater flexibility. 
Approaches used so far have been : a) let the 
program decide what to save and restore, b) 
implement through hardware an automatic 
store sequence to save registers in memory 
and automatically restore after completion, 
and c) maintain all registers in memory and 
provide multiple register groups for each in- 
terrupt routine and the main program (when 
an interrupt occurs, a pointer automatically 
selects the unique register group). The first 
approach is generally effective if the instruc- 
tion set is designed to allow many operations 
to occur without affecting any (or few) regis- 
ters. In this way, the programmer has alter- 
native choices to keep the overhead low. The 
second approach involves a fixed overhead no 
matter what functions are performed in the 
interrupt routine. The third approach gives a 
very desirable flexibility to the interrupt capa- 
bility. If, however, the registers are accessible 
at the same cycle time as instructions, the 
tendency is to slow the whole computer down 
just for the' sake of interrupt capability. 

Future computer design, representing a de- 
parture from the conventional structure, must 
effectively solve this problem and reduce the 
overhead even further than is now done. 
While this factor does not reduce the efficiency 
of the computer as a transponder as much as 
some of the other factors, it limits the maxi- 
mum efficiency obtainable in on-line systems. 
Ideally, the overhead time should approach 
zero. 

INTERRUPT ARM/DISARM 
CAPABILITY 
In more complex on-line applications, the 
requirement occasionally exists for inhibiting 
recognition of some interrupt requests while 
other functions are being performed. For ex- 
ample, a high speed transmission such as a 
disk transfer, which may have low priority 
until the instant that the request has been 
initiated, must capitalize most of the compu- 
ter time. If the priority structure is allowed 
to stand, higher priority items might inter- 
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fere with the transfer and cause transmission 
errors due to loss of information. On the other 
hand, the system may require that certain 
critical interrupt lines remain open at all 
times so that the prevention of all interrupts 
is not feasible. This situation requires the use 
of an interrupt arm/ disarm capability. To do 
this, a flip-flop is placed on each required 
interrupt line external to the interrupt control 
system. Each flip-flop must be under control 
of the central computer. When the flip-flop is 
SET by the central computer, interrupt re- 
quests can be recognized and the interrupt 
line is said to be armed. Correspondingly, 
when RESET, interrupt requests are inhib- 
ited and the interrupt line is disarmed. To 
conserve computer time, interrupt arm/dis- 
arm flip-flops are usually placed in the desired 
state in multiple groups rather than singly. 

PRIORITY INTERACTIONS 

Assignment of priority interrupt levels to 
particular functions in a given on-line system 
is, at times, an interesting and perplexing 
problem. At first, it appears that the systems 
designer should order the request functions 
on the basis of importance and assign levels 
accordingly. This, however, produces the most 
effective system performance only by acci- 
dent. Priorities must be assigned using the 
interaction of functions with each other as a 
primary basis. 



Consider a simple on-line control system 
with three major requirements: (1) receive 
and modify input data, (2) output these data, 
and (3) maintain time in milliseconds. The 
estimated length of execution of these func- 
tions and the worst case frequency of occur- 
rence is shown in Figure 3 . 

In this hypothetical case, the maintenance 
of time is for future off-line processing and 
is the least important of the three functions. 
Since the output of data is possible only after 
data input and modification has occurred, sys- 
tem input is the most important function. If 
priority were assigned strictly on the basis of 
importance, the time function will be missed 
under certain conditions. This erroneous time 
measurement cannot be tolerated. If, however, 
the time function is assigned the highest pri- 
ority (as shown), no time information will be 
lost. More important, the net effect of this 
assignment is to prolong either system input 
or system output by a few microseconds. Since 
worst case conditions are shown, no serious 
problem results and system saturation is 
avoided. 

The on-line systems designer must ensure 
that all possible interrupts in the system are 
operating compatibly with each other when 
worst-case conditions occur. Debugging on- 
line systems with incompatible priority inter- 
rupt assignments is, at best, a horrendous 
task. These problems must be solved during 
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the design of the system— not during program 
and hardware checkout. System interactions 
involving priority interrupts are often not 
observable during system checkout. 

Even when trouble is detectable, it presents 
to the human a behavior pattern similar to an 
intermittent component failure. This gener- 
ally leads to many false and frustrating excur- 
sions before a solution is found. 

DYNAMIC PRIORITY REALLOCATION 
Based on the occurrence of certain events, it 
may be necessary to reassign the priority 
levels of key interrupts dynamically under 
program control. This requirement is fairly 
common in military command and control sys- 
tems resulting from a change in the tactical 
situation. This capability has been imple- 
mented in a number of ways on different sys- 
tems. Implementation has ranged from large 
banks of flip-flops to core switching matrices. 
Typically, a large amount of expensive hard- 
ware is necessary if total flexibility is re- 
quired. 

If only a few different options of dynamic 
priority reallocation are required in an on-line 
system, it is usually cheaper to assign a given 
interrupt request line to two or three different 
priority levels in the interrupt system. Coupled 
with arm/disarm capability on each line, each 
request can be reassigned to a different prior- 
ity level as the situation changes. This method 
is generally less expensive than the more 
flexible approaches. 

FUTURE REQUIREMENTS 

At least two advances are required in the 
priority interrupt area to make effective use 
of the higher performance hardware being 
developed for on-line systems use. They are 
time related priority assignments and exter- 
nally weighted priority. 

Time Related Priority Assignments 

Existing techniques are not adequate to 
handle a phenomenon which is appearing 
more frequently as on-line systems become 
more complex— the time related priority as- 
signment. Consider an on-line system with a 
low priority task requirement of once each 
second. Immediately after this function has 
been completed, it should have the lowest 
priority in the system. On the other hand, if 
a whole second has passed since execution its 



priority should be high. What is required then 
is a technique which allows this function to 
"creep" upwards in priority as a function of 
time. This case continually exists in time 
sharing systems as a given user would like 
to "wait in line" for his next turn even though 
some users have a higher overall priority. 
Present hardware to implement this require- 
ment is very complex and expensive. A soft- 
ware approach, while technically feasible 
using push-down lists, increases overhead pro- 
hibitively and reduces overall efficiency. 

Externally-Weighted Priority 

In on-line multiprocessing environments, 
separate tasks are being performed in a num- 
ber of computers, the results of each having 
only a partial effect on the entire system. 
Priority requests between computers are more 
effective if the requesting computer can 
"qualify" its importance based on the situ- 
ation. The receiving computer can then use 
this qualification as a weighting factor to 
determine the ultimate priority of the request. 

Certain time sharing systems involving 
many users will require a similar capability. 
Let us give the user a number of levels of 
service, selectable at his console, for which 
he will pay different usage rates. The different 
service levels would provide the user with dif- 
ferent priority usage of the time shared com- 
puter, either more frequent access or longer 
on-line time at each access. 

To provide efficient on-line systems of the 
type provided above, externally weighted pri- 
ority must be available without increasing 
overhead. 

CONCLUSION 

The design of an effective priority interrupt 
capability has not always been proportional to 
its contribution to the overall on-line system. 
A weak priority interrupt (or none at all) can 
reduce the number of useful instructions exe- 
cuted by the central computer to as little as 
one-half the total. Excessive computer power 
must then be employed to compensate for the 
loss of computability. As on-line requirements 
become more complex, an increased burden 
must be assumed by use of priority inter- 
rupts. Adequate solutions have not been found 
to meet all foreseen requirements. Yet, we 
are learning to make effective use of what is 
available to make the digital computer prop- 
erly react to the on-line environment. 
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INTRODUCTION 

The use of a digital computer as a personal, 
on-line tool is being successfully achieved on a 
practical basis through the use of various time 
sharing techniques, and another door has been 
opened to new and more interesting applica- 
tions of our computing technology. To achieve 
this, time sharing brings ready accessibility 
and suitable response time to bear upon the 
human user's requirements for direct employ- 
ment of computer services. Thus, personalized 
conversation or "on-line" interaction between 
man and the power of a computing machine 
offers fruitful solutions for today's complex 
and dynamic problems. 

Much has been said about the many advan- 
tages to be gained by allowing human users to 
have direct contact with a computer. This is 
primarily true because most computer users 
previously were required to operate in a job- 
shop environment, very often through one 
or more middlemen, programmers, computer 
operators, keypunchers, etc. This may have 
proved a frustrating and discouraging experi- 
ence to the non-programmer, and, in many 
cases, even to the programmers. The taste of 
freedom and power felt by the on-line user of 
a large computer system can now be realized 
by many rather than a limited few, and this 
sensation has caused many devotees to hail 
the dialogue of man and machine. 

Communications have been, and will con- 
tinue to be, closely allied to the fruitful use of 
computers. In time sharing systems, remote 
computing and multi-processing computer net- 
works depend heavily on various communica- 



tions facilities. By the same token, however, 
sophisticated communications service will also 
be provided by the computers in new electronic 
switching centers, and time sharing systems 
have a vested interest in some of these serv- 
ices. Personalized or "on-line" computing is 
a very powerful service ; it becomes even more 
powerful if it serves a group of individuals 
involved with a common problem. This is, for- 
tunately, not only achievable within the frame- 
work of time sharing systems, but may be 
done with relative ease. A time sharing sys- 
tem, with its communication lines extended to 
a number of user consoles, is, in effect, a com- 
munications switching center not only be- 
tween the consoles (or other computers) but 
also for user programs. This last feature adds 
the facility of interactivity in the time shar- 
ing environment. 

APPLICATIONS OF GROUP 
COMMUNICATION TECHNIQUES 

Man is a gregarious animal, and a machine, 
albeit a computing machine, is still, after all, 
a machine. The social environment of problem 
solving has often emphasized the concept of 
two heads being better than one. Now that a 
personalized computer is available, which may 
act as a helpful and efficient assistant, the 
popular phrase might be changed to: "Two 
heads and a computer are better than one 
head and a computer." 

There are a number of computer applica- 
tions in which two or more people will inter- 



* Member of the Technical Staff, 
Scientific Data Systems. 



69 



act in some way with each other as well as 
with a computer program or programs. 
Variations may occur in the manner by which 
communications between participants will be 
controlled and these will be discussed later in 
this paper. However, at this point, let us 
briefly review some of these applications. 

Experimental Games 

Time sharing communication techniques are 
essential to computer based experimental 
games with human subjects. Programs for 
such experiments must be designed for mul- 
tiple users, must control and restrict station 
input and outputs, and must allow the experi- 
menter or umpire to time the experiment, 
observe all participants' input actions, and 
intervene when necessary. At his station, the 
experimenter can specify which stations par- 
ticipate in the game, and may alone use the 
full input and output capabilities of the experi- 
mental program. Also, he alone may issue 
executive commands to the time sharing sys- 
tem during the course of the experiment. 

Group Debugging or System Testing 

Since computer programs are growing in 
size and complexity, it is usually necessary to 
partition the development of a large "system" 
among several programmers. Eventually, the 
program components will require checkout as 
a system, and the programmers must debug 
their code together. As the group watches the 
operation of the program at individual (and 
remote) system consoles, and a fault is de- 
tected in an area of code, the person respon- 
sible for the particular code can use on-line 
debugging facilities to fix the trouble; if the 
problem is more complicated, the group mem- 
bers can then discuss the situation directly in 
a "conversation mode" between stations. As 
a last resort, the group can call in an "expert," 
as described below. 

Consultation 

Many types of programming services will 
be available to users of the time sharing sys- 
tem; some fairly complex to a neophyte. The 
time sharing system executive can respond to 
a call for "help" in particular types of opera- 
tions, providing an expert "teacher" for 
language systems, the time sharing system 
itself, mathematical and statistical routines, 
etc. First, the expert may communicate direct- 
ly with a user via a "conversation mode" to 
discuss the problem; then he may find it 



practical to have the user re-enact the opera- 
tion that caused difficulties. The user's opera- 
tion can be put into a "trap" mode by the 
system, allowing the expert to correct the 
user's inputs before processing takes place. 
Alternatively, the expert can demonstrate an 
operation for the user, with the latter playing 
a passive, observer's role. Whichever the alter- 
native, the stations of the user and the expert 
would be linked by the time sharing system. 

Demonstrations 

The on-line technique of consultation de- 
scribed above is also effective for educational 
demonstrations to groups of users. Here the 
demonstrator links his station channel to the 
users' channels so that they can all see his 
inputs and outputs. He may accompany his 
operation by narration through a "conversa- 
tion mode" facility, which encompasses all the 
observing stations (party line). The observers 
may at any time send questions to the demon- 
strator's station as well as to all the other 
observers. Further, during or after the initial 
demonstration, the observers may use the 
consultation mode to perform the operation 
themselves, under the guidance of the expert. 

Briefings 

Communication facilities also serve for con- 
ferences on operational information in a 
user's system. One or more individuals con- 
trol such briefings, calling upon the opera- 
tional object program to present an informa- 
tion display to the various stations. Normally, 
only the briefing control station can have 
inputs to the operational (briefing) program, 
but all stations will receive display outputs. 
Briefing control, however, can be dynamically 
delegated to any appropriate station in the 
group, when necessary. 

Since much of a briefing is often "canned" 
in advance, users may prepare their briefing 
displays during a dry run, attaching retrieval 
"labels" to specific data presentation pack- 
ages, and, if necessary, calling for a basic 
sequence of display of such packages. The se- 
quence does not have to be strictly followed, 
since the user can always call directly for any 
labeled display, or dynamically create a new, 
unlabeled display. 

Common Data-Base Maintenance and Retrieval 

Common to almost all large information 
systems are the acquisition and retrieval of 
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data from many sources and users. Oper- 
ational communication is effectively per- 
formed indirectly through a common opera- 
tional data base, the object program system 
servicing a group of users by either updating 
the data base or by retrieving information 
from the data base. Here, a non-replicating 
program design is advisable to service many 
users in a parallel fashion without costly pro- 
gram redundancy. Operational controls over 
the program system can limit input of new 
data to some stations, other stations can re- 
trieve data, and some stations can do both. 
Security and quality controls are thus imple- 
mentable via the program system. 

Technical and Administrative Management of a 
Computer System 

In a large programming installation, many 
computer users are engaged in developmen- 
tal and production activities. An outstanding 
problem is often the technical supervisor's 
difficulty in maintaining current awareness 
of what his programmers are doing, such in- 
formation being necessary for scheduling, 
priority assignment, technical evaluation and 
guidance, etc. The time sharing system, while 
serving its full complement of users, can also 
permit a supervisor station to monitor in- 
dividual stations and provide on-line man- 
agerial guidance. The accounting function of 
the time sharing system can provide historical 
data on each user, valuable to the technical 
supervisor for assigning priorities to his 
programmers and directing their on-going 
activity. 

Computer Operator Activities 

One of the more mundane communication 
requirements rests with the need for com- 
puter operator services. Users of a time shar- 
ing system must be able to communicate with 
the computer operators for tape handling 
functions, disposition of off-line outputs, ma- 
chine problems, system status information, 
or special communication arrangements. Like- 
wise, computer operators must be able to 
communicate with users to notify them of 
system conditions affecting their operations. 
Although much of this communication can be 
carried out indirectly via the time sharing 
system executive and object programs, un- 
anticipated problems require direct commu- 
nication with the computer operator. 

In many ways, the human elements in the 
man-machine relationship derive significant 



benefits from solving problems and perform- 
ing operational tasks as a group. The soft- 
ware and hardware facilities of a time shar- 
ing system must therefore enable the users, 
including the computer operator, to commu- 
nicate and interact freely, under a variety of 
selective controls, with each other and with 
the computer programs. 

ELEMENTS OF USER COMPUTER 
COMMUNICATION 

Many types of communications can be found 
within the confines of a computer system and 
this is particularly true for time sharing 
systems. We might think of users (people), 
programs, computers, special devices, and 
systems talking to other users (people), pro- 
grams, etc., etc. However, if the proper foun- 
dation is laid for communication between 
these elements, there will be no limit to which 
the thread of interaction may be extended. 

Communication between a computer and a 
human being is not as flexible as between two 
humans, but improvements are rapidly being 
made in this direction (problem oriented lan- 
guages, etc.). The computer can now be made 
more welcome as a powerful resource and in- 
troduced into the problem solving tasks of the 
human world. The problem, then, is to clarify 
and extend communication linkages between 
the human group or organization, and the 
computer programs in the on-line, time shared 
environment. 

Man-Machine and Man-Man interaction 

The most basic types of on-line interaction 
and communication in the time sharing sys- 
tem are those in which the humans directly 
interchange information between themselves 
and those where the interaction takes place 
between "man and machine." When we speak 
of MAN-MACHINE relationships with a dig- 
ital computer system, we, of course, really 
mean a MAN-PROGRAM dialogue. Let us 
examine the mechanisms available to the time 
sharing system users for both of these basic 
forms of interaction. 

Figure 1 illustrates a user station, usually 
remotely situated, equipped with some of the 
current on-line communications hardware. 
All the devices shown are not necessarily 
required, but one can conceive of effective 
applications for all of them. 

A single channel (or unique set of chan- 
nels) between the man and the program per- 
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USER STATION COMPLEX IN THE MAN-MACHINE RELATIONSHIP 



forms the basic man-machine operation, all 
inputs and outputs from various input/output 
devices being confined to an individual user 
and not normally accessible to other users in 
the time sharing system. Figure 2 shows a 
system with a number of users. 

Such arrangements are adequate for the 
"lone wolf" researcher or programmer, since 
maximum privacy is provided for the intimacy 
between a man and his program. However, in 
order to breach the communication gaps be- 
tween user groups, the system executive stands 
out rather logically as being in a strategic ac- 
tion position. 



We cannot assume that in a time sharing 
system environment the conferees are nor- 
mally sitting side-by-side communicating di- 
rectly. Thus, MAN-MAN conferencing will 
proceed either by some communication facility 
independent of the time sharing system (e.g., 
a telephone network, intercom, etc.) or through 
the system itself ( Figure 3 ). 

MAN-MAN communication provided by the 
time sharing system itself is by far the most 
interesting and powerful approach, for we 
can then integrate group activities with the 
many applications of a digital computer. The 
computer becomes a communication center in 





CHANNEL 1 












j^-N 




E 
X 
E 
C 
U 
T 
1 

V 
E 




OBJECT 

PROGRAM 

1 




( 1 1— 






\LS~ 


CHANNEL 2 














/~\ 




OBJECT 

PROGRAM 

2 




( ? j_ 






\y— 


CHANNEL 3 














r\ 




OBJECT 

PROGRAM 

3 




( < ) 






v_y - 


CHANNEL 4 














(TV; 




OBJECT 

PROGRAM 

4 




V/- 


COMMON 
CARRIER 





























FIGURE 2 

MULTI-USER SYSTEM 



72 



USER 
STATIONS 






/-\ CHANNEL 1 








A ' ) 




E 
X 
E 

c 
u 

T 
1 

V 
E 


7 /^\ CHANNEL 2 




/ v v J 




V^\ CHANNEL 3 


i 


( 3 ) 

















COMPUTER 



FIGURE 3 

MAN-MAN COMMUNICATION VIA TIME-SHARING SYSTEM OR EXTERNAL FACILITY 



USER 
STATIONS 



© 



CHANNEL 



© 



CHANNEL 2 



© 



CHANNEL 3 



OBJECT 
PROGRAM 



OBJECT 

PROGRAM 

2 



I OBJECT 
PROGRAM 
3 



COMPUTER 



© 



COMPUTER 
OPERATOR 



FIGURE 4 

MAN-MAN AND MAN-MACHINE COMMUNICATION LINKS IN A TIME-SHARING SYSTEM 



addition to performing operational data proc- 
essing functions. Assuming that all MAN- 
MAN conferencing will normally relate to 
the users' data processing tasks, it is desirable 
that a generalized time sharing system should 
provide selective communication service func- 
tions in response to various user operating 
needs. 

In general, users of an on-line, time sharing 
system will expect the capability for both the 



basic MAN-MACHINE and MAN-MAN com- 
munications, as shown in Figure 4 . If the 
latter type of communication is not provided, 
the system will be operationally constrained 
and will lack a significant degree of flexibility. 
Figure 4 shows the role of the time sharing 
system executive in providing overall com- 
munications service to people and programs. 
Using the system, a user can communicate 
not only with his object program (and the 
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system executive) but with any other user 
station, particularly the computer operator.* 

The communication flexibility thus avail- 
able will help resolve those many unantici- 
pated problems which always manage to show 
up in the best of computer systems. 

Although Figure 4 implies a single proces- 
sor to perform an operation in a time shar- 
ing system, in reality a multi-processor ca- 
pability is desirable for other than very small 
systems. In particular, many of the commu- 
nication functions discussed in this paper 
may be profitably delegated to a separate 
processor which is allied with the system 
executive. 

Men-Machine Interaction 

Going beyond the basic MAN-MACHINE 
relationship described above, the time shar- 
ing system must permit object program com- 
munication with more than one user station 
channel, in order for it to interact with a 
group of users. Such group interaction with 
an object program in a time sharing system 
is one of two types; the first type involves 
object programs designed for many users, the 
second concerns normal, single user programs. 
Responsibility for the first type of group 



communications will rest primarily with the 
object program, not with the time sharing 
system executive. For the second type, the 
executive of the time sharing system can 
facilitate the additional group communica- 
tions. 

Type 1 . Multi-User Object Program 

Two examples of multi-user programs are: 
experimental games with human subjects, 
and public service programs. For experi- 
mental games, the programs are used by a 
designated set of individuals; public service 
programs, on the other hand, are used by a 
randomly varying number of users in a time 
sharing system. The game playing type of 
program, via the time sharing system execu- 
tive, must sequence the input-output activity 
of particular user stations; the public service 
function will usually accept any user station 
randomly*. Both types of programs, however, 
will be required to maintain proper storage 
separation of inputs and outputs and con- 
textual data for each user station involved. 
Furthermore, for both types of operations, 
the time sharing executive must permit these 
programs to be linked to more than one 
user-communication channel ( See Figure 5 ). 
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Hard copy communications are best suited for the 
computer operator servicing many users, since he 
can answer queued requests as time permits. Voice 
communication requires time for listening and mak- 
ing notes as well as limiting the operator's attention 
to one user at a time. 



Exceptions to this rule may be certain production 
functions (compilations), run only by the com- 
puter operator's station. In such cases, only one 
such job may actually be serviced at a time. 
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The terms "pure program", re-entrant or 
transparent routine have been used to de- 
scribe the design of a program that can 
accommodate a number of independent users 
simultaneously. (The general service program 
is an example.) 

The pure program does not modify its own 
instruction code, it maintains all contextual 
information in reference storage, and the 
time sharing executive provides the proper 
environment for each user channel to the 
object program at operation time. This tech- 
nique permits the program to be interrupted 
at any time and to process a number of user 
requests nonsequentially. The pure program 
approach, although primarily useful for inde- 
pendent users' interaction with a service type 
program, can also be used for common group 
operational functions, such as staff activities 
involving on-line data acquisition and re- 
trieval. Time and storage demands on the 
system will thus be reduced by the common 
use of a single processor rather than by repli- 
cation of routines for each user. 

Type 2. Programs Designed for One User 
Operation 

Many object programs are designed for an 
individual user; if more than one user re- 
quires the use of such a program, it will 



simply be replicated in the time sharing sys- 
tem. There are, however, numerous instances 
when such a program should be accessible to 
more than one user channel simultaneously 
without replication. For example, when the 
program is complex enough to require check- 
out analysis and debugging by a group of re- 
sponsible persons (system test), or when op- 
erational control of a program system must 
reside with a select group of limited size. In 
effect, what is needed is a "party line" com- 
munication link to the program. 

For a one-user program to operate with a 
group of users, we must "patch" the station 
channels of the participants. The user group 
thus can confer with the object program, and, 
depending upon the selectivity of the patch- 
ing, all individuals in the group can monitor 
each other's inputs and all program outputs. 

The executive-performed channel patching 
shown in Figure 6 has distinct advantages: 
it does not require manual intervention; it 
does give selectivity to the user, i.e. the user's 
channel can be set to receive output copies 
only, receive copies of other inputs as well, 
insert inputs, or exercise master control over 
other channels. 

Alternative to executive program patching 
is the "looping" of user channels on the 
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equipment side which provides rather limited, 
unsophisticated capabilities. ( See Figure 7.) 

A critical requirement for the Type 2 situ- 
ation is the provision of proper operating 
procedures. In short, the users must know 
how to interact in an orderly manner with 
their program and between themselves, since 
neither the object program nor (to a large 
extent) the executive can really control the 
sequence of multi-station input and outputs. 
For example, organized procedures might in- 
voke a user round-robin order of inputs con- 
trolled by the executive, or direct, MAN- 
MAN party line communication can be 
employed prior to any computer inputs. This 



is an interesting problem area which requires 
much "idiot proofing" in its solution. 

Man-Machine-Machine-Man Interaction 

Just as two individuals interact directly in 
a problem solving task, two or more indi- 
viduals with "computer assistants" can also 
interact profitably. Here, the human com- 
munication can be direct, as described earlier, 
except that two or more programs provide 
the communication linkage and may act as 
intermediate processors of the data being 
referenced by the users. 

Figure 8 shows such an arrangement, 
where the communicants and their programs 
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are not resident in the same machine or 
necessarily in the same system . 

The object programs may converse with 
each other via the good services of the all 
knowing executive, in much the same manner 
as input/output service is provided. 

Computer-to-computer communication 
avails the remote user of the full input/output 
capabilities of his machine, rather than re- 
stricting him to the particular type of pro- 
cessing or input/output capabilities of the 
remote computer (e.g. the Teletype). This 
capability is particularly necessary for dealing 
with large amounts of data than can, for 
example, be scanned on a display scope. If the 
computers involved are similar, binary pro- 
grams and corrections can even be inter- 
changed from one to the other. 

IMPLICATIONS FOR TIME SHARING 
SYSTEM DESIGN 

To achieve the system communication capa- 
bilities described, we must recognize implica- 
tions for the design logic of a time sharing 
system. The actual design techniques will vary 
with the type of computer and communication 
devices being employed and with operational 
programming constraints. 

Communication Modes 

In communicating with the computer, the 
user will address a program level or other 
users. By program level we mean the pro- 
grams or parts of a program with which we 
desire to communicate. In a general time 



sharing system we normally have: executive 

programs— basic control or service functions, 

and object program or systems— operational 

functions. 

As shown in Figure 9 , we may find levels on 

levels of input communications. 

A simple two-way switch for communica- 
tion modes may be provided, allowing inputs 
to either the executive programs or object 
programs. A third mode, immediate MAN- 
MAN communication, provides a useful ex- 
tension, for with this mechanism a user can 
simply indicate the addressee station once. 
Now, whenever he wishes direct communica- 
tion with these stations, he inputs the "con- 
ference" indicator and his message goes 
through the system directly to the previously 
referenced stations. This mode switch will fa- 
cilitate rapid shifting from MAN-MACHINE 
to MAN-MAN communication and interaction. 

Message Queuing, Control, and Addressing 

As in any communication network, a time 
sharing system must control the acceptance 
and routing of MAN-MAN conversation mes- 
sages, particularly in respect to the competi- 
tion between such messages and MAN-MA- 
CHINE (program) output communications. 
The system executive must store MAN-MAN 
messages until the receiver's channel is free. 
Depending upon the size of the buffer storage 
and the traffic volume, a sender may get 
a "busy" signal because buffer storage is 
unavailable. Further, it is desirable to allow 
the receiver to schedule the delivery of such a 
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message. Thus, he might tell the system that 
he is "busy," and no extraneous messages 
would be delivered to him directly. He would, 
instead, be alerted if a message were waiting, 
and could subsequently allow transmission at 
his convenience. 

A user's communication "address" is usu- 
ally the physical channel connecting his sta- 
tion to the time sharing system. Even though 
several users share a station in the time shar- 
ing system, hard copy messages can be de- 
livered to a station for further hand delivery 
to the specific individual concerned. 

An established time sharing station network 
can have mnemonics for "administrative" and 
"technical" station addresses: "dial" for 
the computer operator, S for special priority 
scheduling, C for complaint department, etc. 
A station directory would be necessary in the 
system to reflect dynamic updating of station 
addresses as organizational responsibilities are 
shifted. 

Multiple addresses, of course, should be an 
available feature for group communication. 
A message can thus contain several station 
numbers and all would receive copies of the 
message. For the convenience of the system 
supervisor or the computer operators, an 
"ALL" address permits sending broadcast 
notices to all users in the system. 

Scheduling Considerations 

Time sharing systems operate on the princi- 
ple of allocating computer time to various 



users on some equitable basis. In the basic 
MAN-MACHINE relationship, a given pro- 
gram would be operated for a single user. 
This allows a one-to-one correspondence be- 
tween allocated time for a program and its 
user. However, when a group of users is as- 
sociated with a single program, the question 
arises as to how much operating time should 
be given to that program. If time allocation 
is really determined on a user basis, then a 
program should be allowed to operate for n 
times the normal "quantum" (slice of time 
allocated per queue cycle), where n is the 
number of user stations linked to the specific 
program. 

This can easily be done if the scheduling 
queue is station oriented and the object pro- 
gram is linked to each of the associated station 
channels. ( Figure 10 .) If a simple patching 
is performed, where the stations are really 
linked to one channel ( Figure 11), the situa- 
tion is more questionable for providing addi- 
tional operating time to the program. Essen- 
tially, operating quanta are allocated on the 
basis of an on-line response cycle (e.g. maxi- 
mum 2 seconds), wherein each program should 
service its user at least once. If a program 
provides "simultaneous" service, as in Figure 
10, n quanta should be made available to the 
program. In the case of Figure 1 1 , sequential 
service is being offered to n users. In the 
latter situation, only one quantum is necessary 
per response cycle, since only one of the n 
users can interact properly each time. 
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CONTROL OF GROUP 
COMMUNICATION AND INTERACTION 

Assuming that MAN-MACHINE, MEN- 
MACHINE, and MAN-MAN communications 
should all be provided, we must also admit 
that it is necessary to control such communica- 
tions in operational group activity. Since the 
computer system acts as a central switching 
center, any controls and restrictions over the 
group operation can be supported or enforced 
by the time sharing system executive in con- 
junction with the object program. 

We must consider the following control 
questions: Who can originate the activity? 
Does the originator designate the participants? 
Will any participants be restricted to specific 
input or output media? Can the originator 
(control station) dynamically change the oper- 
ting restrictions on individual participants? 
Who may terminate the entire operation ? Can 
an individual station terminate its own par- 
ticipation without disturbing the group? Can 
any particular station in the group receive 
priority processing of its input? 

We can properly control a group computer 
operation only when the executive program 
links the user channels. If the participating 
stations are looped by external hardware 
methods, such that the object program deals 
with only "one" physical station channel, then 



no selective control can be performed, except 
possibly by very awkward means. For effective 
control functions in a group operation, the 
object program must be designed for multiple 
user channels. The station originating the 
activity can control the object program func- 
tions in terms of initiating and terminating 
its operation in the time sharing system and 
specifying participating stations with associ- 
ated input or output restrictions. Other types 
of control can then be made possible primarily 
by appropriate design of the object program 
and executive communication services. 

EXPERIENCE WITH GROUP 
INTERCOMMUNICATION 
There are not many large, generalized time 
sharing systems in existence, and specialized 
multi-station systems (e.g. reservation sys- 
tems) are usually confined to either single- 
channel inquiry or data acquisition operations. 
Therefore, much of the full potential of group 
on-line interaction with computer programs 
remains to be explored. However, some logical 
aspects of group communication facilities have 
manifested themselves, particularly in TSS, 
the time sharing system created on the AN/ 
FSQ-32 computer by System Development 
Corporation. This system has both local tele- 
type stations and terminals for remote users 
employing common carrier facilities. In ad- 
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dition, a 2KC terminal is available for remote 
computer utilization. 

The three basic types of inter-station com- 
munication provided in TSS are : JOIN, DIAL, 
and LINK. 

JOIN 

Several stations may be joined to a com- 
mon program only through the program itself. 
Primarily a service for experimental games, 
joining may be initiated by the originating 
station (through the game program) to in- 
clude other specified stations. The executive 
considers each designated station as a distinct, 
valid user channel to the same common pro- 
gram. On the executive level of communica- 
tion, each joined station can operate almost 
individually. "Almost", because certain ob- 
vious restrictions are made upon the joined 
stations to prevent disruption of group opera- 
tion by an individual. Such restrictions in- 
clude preventing a change of program status 
to a non-operating mode, i.e. debugging mode, 
stop or quit status. Individual stations may 
remove only themselves from the group by 
quitting; only the originating station may 
stop or terminate the program by executive 
action. 

Joining service primarily provides multi- 
user input service to an object program; out- 
put messages are directly addressed to specific 
station numbers. This means that any object 
program may be used to generate output mes- 
sages to any user station (one at a time). 

The most obvious problem for "joined" 
stations, namely the proper sequencing of the 
multiple user access to the common program, 
was not a very difficult one, since the schedul- 
ing logic was based on a fixed, channel table. 
However, human errors, as usual, predominate 
in an on-line system, and special precautions 
on joining had to be made. 

The originating station has to be prevented 
from joining a stranger against his will, that 
is, an independent user might suddenly find 
himself joined with an experimental game that 
he really has no part of. Thus, only inactive 
(no programs loaded) stations may be joined. 
As mentioned earlier, any individual joined 
station (except the originator) must not issue 
executive commands which will disrupt the 
remaining group. Those commands which can 
affect the operating program status, such as 
stop, quit, and debugging commands, are only 
honored from the originating station. A joined 



station can stop or quit his individual partici- 
pation any time. An additional requirement 
showed up when the wrong station became 
joined accidentally, or if participation was to 
be terminated for any joined station. If the 
station was remotely located and if the sta- 
tion's user would not or could not effect ter- 
mination (quit), the joined status could not be 
undone. For this reason, the UNJOIN com- 
mand was added. (The originating station, 
obviously, may not be unjoined.) 

The JOIN function has proved quite valu- 
able for various experimental exercises using 
groups of live subjects. In several cases, the 
game playing group involved remote user par- 
ticipation utilizing common carrier connec- 
tions. Supplementary direct conversation was 
provided through the DIAL function described 
below. 

DIAL 

The DIAL function permits station-to-sta- 
tion communication through an executive com- 
mand. One or more stations may be specified 
as addressees and a message of limited size 
(total length of one teletype line, including 
command and addressees) will be delivered 
immediately by the executive. Delivery is made 
as soon as the receiving station's output buffer 
is ready. All stations may be dialed simul- 
taneously (by the computer operator) for a 
public broadcast. 

The DIAL capacity was very essential to 
TSS in its formative stage, since it was (and, 
to some extent, still is) a tape dependent 
system before the disk was installed. Station 
communication with the computer operators 
was quite heavy, and the DIAL command 
proved to be a significant asset. 

The main problems which the DIAL func- 
tion imposed, included interference with user 
program output, restriction on message 
lengths, and the necessity of formally giving 
the DIAL command each time. Very often, 
formatted program output would suddenly be 
interrupted by a DIAL message from another 
station. This could be most annoying to the 
on-line user, especially if it were a "wrong 
number". Because of the limit on DIAL mes- 
sage lengths, messages had to be segmented, 
and, frequently, some trailing characters of 
the mesage were truncated. Improvements to 
DIAL service were contingent on acquiring 
more storage (disc) for executive services, 
and such improvements are being made. 
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LINK 

The linking capability enables two stations 
to act in concert with an object program, 
where the program has normal access to a 
single user. Any station may LINK to another 
station that is not currently linked. A LINK 
notice appears at both stations, stating who 
is linked to whom. Both stations are now in 
communication with the object program, if 
any, that was operating for the user that was 
linked to ("linkee"). All inputs and outputs 
to and from the system are immediately seen 
at both stations, and a "conversation" mode 
is provided for unlimited, direct communica- 
tion between the linked stations. 

The LINK operation became at the same 
time a most interesting function and an in- 
teresting problem. In its simple form, the 
LINK function has been used for remote 
demonstrations, monitoring of various on-line 
operations, joint debugging, and for consul- 
tation and teaching services to new, remote 
users. Perhaps one of the most unexpected 
payoffs from the LINK feature was the ability 
for a user to operate several programs in 
parallel. By linking to unused channels, the 
user could initiate an operation, unlink, and 
repeat this action on another channel. He may 
then periodically check any of his linked 
operations at will. Obviously, such an ap- 
proach is highly useful for production tasks 
and becomes an aid to the computer operator 
for background work. 

The LINK function is a public one, avail- 
able to any user station. The problem of un- 
expected output interruption (as for DIAL) 
was present and complicated by the fact that 
the "intruder" was now able to lay hands on 
the user's program. The linking station could 
issue a termination (quit) and thereby destroy 
the "linkee's" entire operation. Then too, cases 
occurred where sensitive information was 
being output and, by using the LINK function, 
a stranger could see the restricted data. Al- 
though either of the linked stations could un- 
link, they could also interfere with and pre- 
vent that action from taking place. It was 
no wonder then, that during a local demon- 
stration that was to be monitored remotely, 
as soon as the LINK notice appeared on the 
demonstrator's Teletype, he quickly panicked 
and appealed to be unlinked because his visi- 
tors were arriving at any moment. 

Another problem often occurred in using the 



LINK facility for teaching. It became neces- 
sary for the neophyte to avoid interfering, 
accidentally or otherwise, with the consult- 
ant's input actions. Since only unenforceable, 
procedural rules could be provided, this was 
not always possible. Something more positive, 
that would render one of the linked stations 
passive (in terms of input), was required. 

As a result of these various problems with 
linking, variations were designed for this 
function. For simple monitoring (watching) 
of another station's operation, a "secret" link 
(SLINK) would be used. This did not cause 
any disruptive printout on the monitored 
station's teletype. Furthermore, no inputs 
from the monitoring station could be directed 
to the monitored program or seen at the 
monitored teletype. In effect, this form of 
linking involved only output monitoring. 

To cope with the problem of disarming any 
interference from a linked station, a "passive" 
link (PLINK) could be employed. This feature 
prohibited all program or system inputs from 
the monitored station from being honored, 
although all inputs (and outputs) from the 
monitoring station could be seen. This form 
of control would be enabled and disabled at 
will by the monitor station. 

Finally, a STOP LINK command to the 
system would prohibit any station from being 
able to link to a user's station in any fashion. 
This defense would be required in the face 
of a potential invasion of privacy by linking. 

All of the above three functions require 
administrative approval before being activated 
by the time saving executive, and thus such 
commands would be forwarded to an adminis- 
trative channel (i.e. the computer operator) 
for permission. 

A remaining LINK feature which may be 
implemented in the future, is to link more 
than two stations together and impose a cer- 
tain amount of procedural control over such 
group activity. Programs may behave (i.e. be 
debugged) but the human operators may not. 
In the real world of human fallibility, it is 
essential to provide proper controls, idiot 
proofing, escape hatches, etc., for the effective 
employment of on-line computer systems. 

CONCLUSION 

The on-line approach provided by time shar- 
ing will accelerate the usefulness of computers 
many fold. Direct MAN-MACHINE inter- 
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action and pooling of software services will 
make a computer much more flexible and re- 
sponsive to the needs of individual users. How- 
ever, it is important to consider the com- 
munication and interaction needs of groups 
of users with computer programs, to realize 
more fully the benefits of computer assistance. 
By making provisions for interaction of MAN- 
MAN, MEN-MACHINE, etc., the human 
relationship with computers will not be un- 
naturally restricted and greater rapport be- 
tween man and machine elements in computer- 
based systems will ensue. 
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Message Switching Plus 



INTRODUCTION 

The term "message switching", when refer- 
ring to an application of a digital computer, 
has been almost exclusively related to the 
switching (and related functions) of telegraph 
messages. The message switching function has 
crept into many fields of computer usage— in 
fact, wherever communications circuits are 
terminated at a digital computer. This fact 
makes it mandatory that we enlarge our con- 
cept of message switching to include these 
other applications. In particular, we need to 
see what implications on hardware and soft- 
ware design and standards this enlarged view 
may have. 

The marriage of communications and com- 
puters is taking many forms. Among the more 
easily recognizable are: (1) query networks 
(reservations, stock market statistics, credit, 
library reference, any inventory situation) ; 
(2) data collection networks (personnel "time" 
data, move station data on assembly lines, 
instrumentation data in a process control en- 
vironment, location of shipments in transpor- 
tation systems) ; (3) time sharing of com- 
puters among remote users (Project-MAC 
type) ; (4) man-console-computer association 
in the solution of unstructured problems (the 
so-called on-line computing technique) ; (5) 
computer-to-computer hook-ups for sharing 
load or dividing processing functions; (6) re- 
mote distribution of the results of automatic 
data processing; and (7) the switching of 
telegraph messages. 

Each of these many forms of communica- 
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tions involving computers has its own pecu- 
liarities, and yet there are many functions and 
features which are common to several or to 
all. It would appear timely to assess these 
features for their commonality and their pecu- 
liarities in order to guide those responsible for 
the development of new hardware, new soft- 
ware, and new techniques in their search for 
efficient and compatible solutions. 

This paper describes a computer controlled 
communications network which contains all 
elements necessary to serve the common on- 
line applications involving computers and com- 
munications, and can time share its facilities 
among any combination of such applications. 

"UNIVERSAL" COMPUTER- 
CONTROLLED COMMUNICATIONS 
NETWORK 

The parent network from which any of the 
above enumerated systems may be derived is 
simple to describe. A digital computer is pro- 
vided with a multiplicity of input/output data 
channels, some of which terminate in commu- 
nications lines. Other terminations include a 
data bank, direct input devices, direct output 
devices, consoles, and other computers. The 
communications lines, in turn, may terminate 
at input devices, output devices, (consoles, 
telegraph stations), another computer's com- 
munications terminal, or another telegraph 
central. See Figure 1. 

To the best of the author's knowledge, no 
single computer installation to date involves 
all elements of this parent network. Each 
application enumerated above is satisfied with 
a subset of these elements. The question may 
properly be asked if there, is any need to con- 
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"UNIVERSAL" COMPUTER-CONTROLLED COMMUNICATIONS NETWORK 



sider the parent network as one for which a 
demand will arise. 

As the techniques and hardware for utiliz- 
ing a digital computer from a remote location 
become more capable and less costly— and both 
trends are strong today— the pressure to use 
existing facilities more efficiently will grow. 
For example, much of the telegraph traffic 
handled by the common carriers is carried 
over voice-grade lines, but at telegraph speeds. 
Yet in many systems, the line costs are the 
largest single element in the user's budget. If 
the user could terminate these long lines in a 
computer already present for the other neces- 
sary functions, the traffic rate over the high 
cost lines could be increased 30 fold with only 
a three times increase in tariff. Users employ- 
ing multi-circuit facilities at reduced tariffs 
(such as Telpak) could realize such increase 
in traffic carrying capacity at no increase in 
cost. 

The need to time share the communications 
lines among several functions within an or- 
ganization is developing rapidly— not only for 
economic reasons, but to capture vital infor- 



mation for use in several application areas. 
Such time sharing becomes feasible only if 
the full network of Figure 1 can be implemen- 
ted. The problems to be solved before these 
goals can be reached are many, but not insur- 
mountable. 

MESSAGE SWITCHING IN THE 
"UNIVERSAL" NETWORK 

Messages may originate from many types 
of input devices— instruments, radio receivers, 
A-D converters, keyboard, paper-tape readers, 
card readers, magnetic tape readers, and com- 
puters. The network must control the initiation 
of the message, or be able to respond to an 
arbitrary initiation. The connecting commu- 
nications line may be simplex, half -duplex, or 
full-duplex. The simplex line permits trans- 
mission in one direction only— out-station to 
computer or computer to out-station. The full- 
duplex line contains two independent simplex 
circuits, one for each direction of transmis- 
sion. The half -duplex line contains only one 
circuit, but the direction of transmission is 
reversible. Since both transmitting and receiv- 
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ing stations must reverse direction simulta- 
neously, some means of controlling the rever- 
sals must be provided in either out-station or 
computer. 

In one type of controlled operation (such as 
telegraph out-stations on a "party" line), the 
computer is idle in the transmit mode, where- 
as the out-station is idle in the receive mode. 
Periodically, the computer sends a polling 
symbol unique to the out-station and reverses 
its mode. Upon recognizing its "name" symbol, 
the out-station reverses its mode, if opera- 
tional, and responds within a given period of 
time. If the out-station is operational but has 
no traffic to transmit, it must respond to the 
polling symbol with a unique no-traffic symbol. 
If the response is a message, the first message 
character or start-of -message symbol must be 
different from the no-traffic symbol. There 
must be a unique end-of -message symbol. The 
line is held by the polled out-station until (a) 
it generates a no-traffic symbol, (b) it gen- 
erates an end-of -message symbol, or (c) it 
generates no symbol during the allowed re- 
sponding time. The line reverts to the control 
of the computer upon the occurrence of one 
of the situations (a), (b), or (c), and remains 
under computer control until the computer 
transmits another polling symbol. Many out- 
stations may share the same line, but only one 
may transmit at a time. 

In a second type of controlled operation 
(such as query networks using "party" lines), 
the computer is idle in the receive mode and 
the out-station is idle in the transmit mode. A 
local controller performs the function analo- 
gous to polling, which permits each connected 
out-station, in turn, to gain access to the line 
when it is seeking to transmit. Once the access 
has been granted, the controller locks on to 
the selected out-station until the return mes- 
sage from the computer to that out-station has 
been completed, whereupon both computer 
and out-station revert to their respective idle 
modes. 

In the uncontrolled mode, the input station 
may initiate a message at any time. Opera- 
tionally, this mode is equivalent to that state 
of the controlled mode between transmission 
of a polling symbol and the occurrence of a 
terminating situation (a), (b), or (c). It is 
obvious that only one out-station may be 
allowed this mode of operation on any line, 
and the computer has no control (on this line) 
of the input station. 



Where traffic requirements exceed the ca- 
pacity of one line, or where message lengths 
allow one input station to eclipse another of 
higher priority, it may be advantageous to 
route polling symbols over one line connected 
to many out-stations, whereas the traffic to or 
from these stations is routed over several lines. 

To prevent undue periods of idleness for a 
line, it is desirable for the computer to re- 
spond to a transmission (other than the no- 
traffic symbol) soon after termination of that 
transmission. If the response is a return mes- 
sage, it may be desirable to hold the line open 
until the return message is ready. In other 
cases, the computer response is simply a 
"received OK" or "not received OK" symbol. 
In the latter situation, the computer does 
nothing with the message, expecting a re- 
transmission. 

If the connecting communications line is a 
single circuit (simplex or half-duplex), the in- 
put station can pre-empt the line for indeterm- 
inate periods, as far as computer control is 
concerned. During such periods, traffic may be 
entered by the station which has to be received, 
recognized, and appropriately dealt with by 
the computer. The computer must be able, in 
general, to ascertain: (a) the identity of the 
originator, (b) the start of the message, (c) 
the end of the message, and (d) that portion 
of the message which will determine the na- 
ture of the computer's handling of the message. 

In establishing identity of the originator, 
the line connection at the computer will suf- 
fice if only one originator is possible on this 
line. Otherwise, an originator identity symbol 
must be present in a recognizable place in 
the message. As far as possible, out-station 
identifying symbols should be automatically 
generated and always present. Thus responses 
and return messages can be assured of return 
to the originating input station. 

A start-of -message symbol is not mandatory, 
since the first character to follow an end-of - 
message symbol, a polling symbol, or a start- 
up condition can be assumed to be the first 
character of a new message (except for the 
unique no-traffic symbol, if used). Such a 
symbol is useful, however, to guard against 
accidental or unintentional transmissions, and 
to expedite synchronization following a line 
outage. 

The end-of -message symbol is mandatory in 
controlled-mode operation, and highly desir- 
able, if not mandatory, in the uncontrolled 
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mode. An exception is permitted if all mes- 
sage traffic has the same length of message, 
in which case the end of message is implicit. 
From the message-switching standpoint, the 
most vital part of the message is that which 
contains the characters which determine the 
computer's handling. These may be identified 
by position, such as the first characters of the 
message, or be a set delineated by special start- 
of-address and/or end-of-address symbols. If 
explicitly addressed messages are combined 
with implicitly addressed messages, distinc- 
tive start-of-message symbols are normally 
required. A simple directory reference should 
suffice to categorize the message and initiate 
the appropriate action on the part of the com- 
puter. This action may take many forms, of 
which the following are illustrative: 

1 . Dispatch the message to one or more out- 
going lines, taking cognizance of indicated 
priority and executing all required mes- 
sage edit, audit, and statistical recording 
operations. 

2. Store the message for later treatment. 

3. Acknowledge receipt of the message to the 
originator. 

4. Send rejection message to the originator. 

5. Perform reference to data bank, using 
key compiled from "address" characters 
and/or directory entry. 

6. Establish a status, depending upon the 
content of the message, the directory, 
and/or the data bank entry. 

7. Generate one or more messages to known 
addresses and/or originator depending 
upon the resulting status determination 
and/or including the content of the data 
bank entry. 

8. Initiate a compiler, assembler, or correc- 
tion procedure upon designated program 
elements. 

9. Retrieve and initiate a computation with 
a designated program. 

10. Update a status record for all actions 
taken on this message. 

At the destination end of the communica- 
tions line, the receiving out-station may be the 
counterpart of some input station, or may be 
a "read only" station. If the latter, there must 
be a way for the computer to determine if the 
device is operational, such as its response to 
the receipt of the message. If the connected 
line is half -duplex under controlled operation, 



the out-station is normally in the receive mode 
when idle. However, in the idle state it is 
responsive only to its unique "name" symbol. 
Upon recognizing this, it prepares itself to 
receive and record the message, monitoring 
the character stream for the end-of -message 
symbol. When the end-of-message is recog- 
nized, the station places itself in the transmit 
mode, returns a "received OK" or "received 
not OK" symbol, and then reverts to the 
receive-idle mode. The computer, upon send- 
ing the end-of-message symbol, places itself 
in the receive mode until the station response 
is recognized, or until a time-out occurs. If 
the response is "received not OK", the com- 
puter is normally programmed to repeat the 
message transmission at least once, before 
indicating trouble. 

If the out-station permits both input and 
output, the line must be either half or full- 
duplex. If half-duplex, one of the two types 
of controlled modes must be used. If the com- 
puter controls the idle line, it may transmit 
either a polling symbol to a particular out- 
station in turn, or a directed message to a 
particular out-station. The out-station be- 
haves as an input device if it recognizes its 
polling code, or as an output device if it recog- 
nizes its directed code. If the local controller 
controls the idle line, the line must be held 
for the selected device until the computer 
returns its answer message. 

CONCLUSIONS 

It should be apparent from the foregoing 
that there needs to be a fairly high degree of 
compatibility in the hardware, software, and 
techniques of operating a "universal" compu- 
ter-controlled communications network. Cer- 
tain restrictions are immediately apparent. A 
given communications line must operate in a 
specific mode at a specific speed, and use a 
homogeneous character set. If the line is to be 
shared by stations of several kinds, the re- 
sponse characteristics of all connected stations 
to a given symbol must be identical or mu- 
tually exclusive. 

The computer program can easily be made 
to be "line sensitive". That is, it may expect 
telegraph message traffic over one line, special 
key-set messages over another, and arbitrary 
bit patterns over still another. However, if 
full advantage is to be taken of leased line 
sharing, and particularly if several kinds of 
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message traffic are to be routed over public 
lines, it becomes important to standardize on 
character set, control symbols, and operational 
mode. When a message has been received by 
the computer, it must contain all features 
which will enable it to be processed, dis- 
patched, and the appropriate response made 
to the originator, depending upon its content 
alone. Input line identification should be re- 
placed by identification symbols generated at 
point of origin, or en route. The handling of 
the message should be independent of the 
manner in which the message reaches the 
computer. 

While the computer is capable of translating 
one character set into another, and respond- 
ing to several sets of symbols with the same 
meaning, such requirements lead to more com- 
plex programs, longer throughput time, larger 
memory requirements, and greater chances of 



error, both programming and operational. The 
system should be designed to operate on a 
given character set (ASCII is the official 
standard), one set of internally generated con- 
trol symbols, and lines of as few speeds and 
modes as possible. Where terminal devices 
are incompatible with the above, translation 
hardware should be provided at the interface 
to the system. In the interests of system main- 
tainability, record keeping, and updating, all 
anomolous conditions unavoidably present at 
the outset should be considered temporary, 
and system design should be such that stand- 
ards will eventually be observed in all areas 
of the system— hardware, software, and oper- 
ational techniques. The increase in system 
performance, ease of updating, and smooth- 
ness of operation that can result from such 
observance of standards will more than repay 
the investment. 
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Donn B. Parker* 



Graphical Communication in an 
On-Line System 



INTRODUCTION 

Processing graphical data is a major appli- 
cation of digital computers. This data is usu- 
ally treated in a highly stylized fashion inte- 
grated into specific problem solutions. Treating 
this data in a digitized "picture" type repre- 
sentation and making it the subject of com- 
munication between a man and a computer in 
the man's own real-time frame opens a new 
dimension of applying computers in solving 
design problems. Presented here are the sig- 
nificant parts of an idealized graphic system 
which, if implemented, should make this 
possible in an economical, sophisticated, and 
practical way. This system should prove to be 
a useful design and problem solving tool. The 
basic hardware and software provides a basic 
drawing capability but only as a means to 
achieve real design objectives. An interface 
with application programs and the capability 
to label and treat the data as "things", not 
merely as line segments, provides the design 
and problem-solving capabilities. 

OTHER SYSTEMS AND BACKGROUND 

Already implemented graphic systems exist 
which meet some of the goals and purposes 
of this proposed system in various degrees. 
Such systems as the General Motors Research 
DAC1 System 1 and the RAND Table 2 are used 
for research and development with very basic 
and general software. The MIT Sketchpad 3 
has taken an interesting approach for making 
drawings and doing design. 

The proposed system described here has 
been influenced by the above systems and also 



by systems developed by ITEK Corporation 
and Charles Adams Associates 4 . 

GOALS AND EXAMPLE OF USE 

The goals of this graphic system in provid- 
ing a practical and powerful tool for general 
design activity are economy, ease of use, and 
availability. The console must be comfortable 
to use, an obvious advantage over other meth- 
ods and tools, and minimize human stress. The 
basic features, besides interfacing with design 
application programs, must provide powerful 
and flexible drawing capability in the sense of 
formal engineering drawing, revising draw- 
ings, engineering sketching, and a variety of 
other graphic uses some of which are as yet 
not conceived. 

An example of its use might consist of the 
following. One of several consoles, connected 
to a central computer, is installed in an office 
shared by four design engineers. Information 
from a master file relative to their project is 
available for display by console request. Each 
engineer could make his own formal engineer- 
ing drawings directly on the console. He 
rarely needs a drawing on paper, and when he 
does, discards it after use. He still makes 
sketches at his desk with paper and pencil 
but quickly redraws the useful ones on the 
console cathode ray tube (CRT) during the 
design process and saves information in his 
own working file in the mass storage of the 
computer. He confers with an engineer at 
another console by telephone while they are 
both viewing a drawing and making design 
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changes. Many computer programs requested 
from the consoles aid them in their design 
and analysis. 

HARDWARE AND SOFTWARE 
ORGANIZATION 

The console for this system consists of three 
principal elements— a large cathode ray tube 
(CRT), a keyboard, and a light pen. A large, 
relatively flat faced, circular CRT, with reso- 
lution for one million discrete beam positions, 
is set into a console in a hinged frame so that 
it may be positioned at a variety of angles in 
the manner of a drawing board. The CRT is 
protected by a plate of glass. The console is 
convertible to desk or drafting table heights. 

A light pen of normal pen size, with a 
microswitch on its shank to turn it on and off, 
is connected to a photomultiplier tube with a 
fiber optics cable. The concept of the light pen 
and its operation are well known 5 ' 6 . 

The keyboard is movable and has a mag- 
netic backing. It may be set on .a table surface 
to the left or the right of the user or adjacent 
to the CRT. The objective of its design is to 
keep the mechanical features to a minimum 
thereby reducing the cost and increasing the 
potential reliability of the system. Two of the 
buttons on the keyboard operate in parallel; 
one on each side of the keyboard, for symmetric 
availability of a major function. One button 
operates in parallel with the light pen micro- 
switch. The number of buttons is minimized 
to keep operation of the console simple. Each 
button activates an interrupt line to the com- 
puter. Each is spring-loaded and non-latching. 
Assignment of button functions is software 
controlled, and removable tabs explain their 
use. 

Other possible mechanical features such as 
foot pedals, alphameric keyboard or other 
keys are not included since they complicate 
console operation and increase console costs. 
Also, adequate features are easily introduced 
by software on the CRT. Reversal of these 
decisions could result from future experience. 

Several consoles are driven by a controller 
which contains a display memory, light pen 
interrupt circuitry, and optional character 
generation circuitry. The display memory 
stores the CRT beam driving instructions, 
sequencing instructions, and console designa- 
tion instructions. The beam instructions are 
incremental in X and Y from the last beam 
position, or they instruct beam movement to 



an absolute position. The amount of display 
memory is assigned to each console as needed. 
The rate of generation is 30 to 40 frames per 
second to produce a relatively flicker free pic- 
ture. The amount of beam travel per frame 
need not be excessive because of the limited 
capability of the user to assimilate and make 
use of detailed visual information and because 
of flexibility of software to compensate for 
this limitation. The display memory has its 
most important function as a buffer to give 
the consoles a complete off-line status except 
when an external interrupt initiates changes 
in the display. Capability to display from com- 
puter memory is also required for high speed 
display changes, such as light pen tracking. 

One or more controllers may be used in a 
computer configuration, depending on the ca- 
pacity and speed. The entire computer capa- 
bility may be used to serve consoles, or the 
computer graphics capability may be time 
shared with other peripheral devices and batch 
mode operation. The computer requirements 
in speed, memory capacity, and secondary 
random access storage capacity are consider- 
able in view of the storage needed for com- 
plex digitized drawings and the major pro- 
grammed features to be described. 

The graphics software consists of the resi- 
dent executive to process the console inter- 
rupts, basic subroutine execution, display 
generating routines, application interface, 
applications programs, and library sub-rou- 
tines. The major aspects of the software will 
be presented from the functional point of view 
in terms of console features and capabilities. 

The graphic console features, when speci- 
fied in all detail, constitute a language which 
could be presented in a formal way. This is 
a manual language in contrast to spoken or 
programming languages. As graphics systems 
are developed and used, several such manual 
languages will emerge along with familiar 
problems of attempts at standardization. It is 
hoped that experience and insight already 
gained in language standardization will mini- 
mize this problem. Formation of users' groups, 
communication of graphic construction algo- 
rithms, and an Association for Computing 
Machinery special interest group are already 
foreseen for the near future. 

BASIC FEATURES 
A concept of precise, literal drawing is 
employed. Graphics are described in an analy- 
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tic geometry representation, and topological 
freedoms are not allowed, with one exception. 
When the pen is pointing close to a graphic 
element or to one of its parameters, it is 
assumed that it is pointing at that element 
or parameter in an exact analytic geometric 
sense. If the pen is pointing close to the end 
of a line segment, the computer assumes it is 
not pointing at the line but at the exact end 
point represented in the computer by coordi- 
nate values to the full precision capability of 
the computer. This is one of the most signif- 
icant features of the system. Although the 
construction of graphics is instigated and 
viewed by a man at very low precision, the 
computer completes the construction and saves 
it at a precision far beyond that of the man's 
and the console equipment's capabilities. 

The basic units of data are X and Y coordi- 
nate values, lengths, radii, angles, address 
pointers, and alphameric characters. These 
are combined with geometric, text, logical, 
and display codes to form entities such as 
straight line segment, circle, text, and group 
(see Table 1). A distinction is made between 
a point entity which is a temporary parameter 
for graphic construction and the dot entity 
which is a point entity formally introduced as 
part of the drawing. 

The CRT display surface is divided into two 
types of regions under control of the basic 
software, but it can be changed by application 
programs. The working region is a central 
rectangular or circular area outlined by a dis- 
played frame entity. Graphic construction is 
carried out only in this region. The second is 
called the control region and it constitutes the 
remainder of the display surface. It is used 
to display light button and light register en- 
tities also under control of the basic software 
and changeable by application programs. 





TABLE 1 






LIGHT REGISTERS 


X, 


Temporary, 


Label Display 


Y, 


Temporary 2 


Label Input 


X 2 


Base Angle 


Message Register 


Y 2 


Angle, 


X Frame Location 


Length, 


Angle 2 


Y Frame Location 


Length 2 


Zoom Index 





A light button is a displayed group of al- 
phameric and/or geometric entities which 
when selected, by pointing the light pen at 
any part of it, causes an ON condition. For 
example, the type of geometric entity desired 
for construction is indicated by selecting the 
appropriate line or dot representing a conic 
section displayed in a two-dimensional pro- 
jection of a cone. (See Figure 1). 
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FIGURE 1 

GEOMETRIC LIGHT BUTTON AND CODE MEANINGS 

A light register entity is a blank space for 
display of a number, label, or message with 
its name displayed to the left. The light pen 
is used to pick a register for use by pointing 
at any part of its displayed name. Information 
may be placed in a light register by either the 
user or the computer. Light buttons control 
inter-register transfers, filling, clearing, and 
locking. Message registers contain alphameric 
information for man -computer communica- 
tion. Light registers may be added, deleted, 
modified, or moved by application programs, 
since they and their contents are part of the 
data list in the computer. Table 1 lists the 
light registers provided by the basic software 
and shows the extensiveness of register use 
and insight into console features. 

LIGHT PEN PICKING 
The selection of displayed entities as para- 
meters for use in further construction is the 
most frequently performed function and 
should be the simplest to perform. The light 
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pen is pointed at an entity, the microswitch is 
turned on and then off, and the entity is 
picked. Entities in the working region and 
light registers in the control region may be 
picked. A successful pick is indicated by 
momentary light intensification of the entity 
picked followed by the display of a character 
next to it or surrounding it (in the case of a 
dot). A light button is selected (as opposed 
to picked) by the light pen to cause an action 
to take place. Momentary light intensification 
of the light button shows computer acknowl- 
edgement of the selection. When an entity is 
picked, displayable parameters of the entity 
such as the center of a circle or the focus of 
a parabolic arc are also displayed as small, 
low intensity crosses. 

A large number of entities may be picked 
before they are used in a last-in-first-used 
order. Higher levels of picking are performed 
by subsequent picking of already picked items. 
Picking a circle which has already been picked 
causes the group of entities which contains 
the circle to be picked as a group (not as in- 
dividual entities). The circle remains sepa- 
rately picked. The erase and other functions 
will change the status of items. (See Table 2). 

ENTITY TYPES 
An entity may be created in many ways, 
but only the basic parameters are used to 
store and define the entity. These parameters 
are chosen on the basis of minimizing storage 
requirements and making equation represen- 
tations easy to derive. The entity types avail- 
able in the system and the basic parameters 
which describe them are listed in Table 3. 





TABLE 3 


ENTITY TYPES 


Geometric 




Dot 


X, Y. 


Straight Line Segment 


Al, YiJ X 2 , Y 2 . 


Horizontal Line Segment 


X], Yi ; X 2 . 


Vertical Line Segment 


Xi, Y, ; Y 2 . 


Circle 


X, Y (center); R (radius). 


Circle Arc 


Circle parameters; X,, Y,. 
(beginning point, counter- 
clockwise); X 2l Y 2 (end point). 


Ellipse 


X, Y (center); A (semi-major axis 
length); B (semi-minor axis 
length); L (angle of major axis). 


Ellipse Arc 


Ellipse Parameters; X,, Y,; X 2 , 
Y 2 (circle arc sense). 


Parabolic Arc 


X, Y (vertex); L (axis angle); F 
(focal distance); X,, Y,, X 2 , Y 2 
(circle arc sense). 


Hyperbolic Arc 


X, Y (center point); A 
transverse radius); B (conjugate 
radius); L (angle of major axis); 
X,,Y,,X 2 , Y 2 (circle arc sense). 


Straight Line Segment 
String 


Xo, Yo, X 1( Y,, . . .Xp, Yn. 


Text 


X, Y (lower left corner of first 
character); string of BCD 
characters. 


Group 


List of pointer addresses of 
group members. 


Control Region 


Control Region location. 


Register 


Register name; contents. 


Light Button 


Light button name. 


Frame 


X, Y (center point). 


Application 


Parameters assigned by 
application programs. 





TABLE 2 




STATES OF ENTITIES 


Erased 


No longer exists. 


Non-Displayable 


Exists in the computer data list but is not displayable. 


Displayable 


Exists and is available for display. 


Parameter-Picked 


Is currently displayed, and one of its parameters is in picked status. 


Picked 


Is currently displayed as picked and is in picked status. 


Group Picked 


Is currently displayed as picked, is not itself necessarily picked, but the group 




or higher level group of which it is a member is picked. 
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The geometric entities are limited to planar 
conies. Higher degree curves may be described 
by fitted conic arcs or by the straight line 
segment string. Three-dimensional graphics 
may be described by their two-dimensional 
projections. 

Several line intensities and standard line 
types may be selected by light buttons. Several 
extra line type buttons are left unassigned 
to provide line types for the user or applica- 
tion program designation. Other light buttons 
provide for nondisplay and redisplay by line 
type or line intensity. For example, a drawing 
may be studied with all center lines or all 
dimension lines temporarily non-displayed. 

DATA FORMAT 

The data format of graphics in the com- 
puter is organized to optimize the compromise 
between data compactness, ease of use, and 
flexibility. Some of the n-Element Component 
and Plex ideas of Ross and Rodriguez 7 are 
used. The active data list for a single console 
is stored in a combination of high speed mem- 
ory and secondary storage in a relative ad- 
dressing, blocked structure. 

An entity is headed by a key field identify- 
ing the type of entity, line type, line intensity 
and other parameters defining its current 



status. The next field is a label with contents 
specified by the console user or application 
program. Its many uses include attaching 
design significance to the entity or superim- 
posing a secondary list structure. The third 
field is a pointer which contains the relative 
address of the parent entity if one exists (See 
Figure 2). The remaining fields contain the 
parameters listed in Table 4. 

The data structure makes it possible to 
locate a group in a tree structure from know- 
ing a member of the group or from knowing 
the label attached to a group entity. Entities 
may be grouped by the user at the console 
or by application programs. There are three 
methods of grouping entities for various uses : 
assigning common line types or intensities, 
picking entities for a group entity, and attach- 
ing labels to entities. Picking groups is facili- 
tated by a set of light buttons providing for 
top group picking or picking in incremental 
steps. 

A further breakdown of the data structure 
is possible by separating the X and Y values 
in a point table and providing pointers in an 
entity array to locate its point parameters. 
There seems to be no advantage in doing this 
in a two-dimensional system either in storage 
savings or program simplification. 
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FIGURE 2 TREE STRUCTURE OF GROUPS 
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ORDER DEPENDENCE 
The console features, especially order de- 
pendence to be described here, are sophistica- 
ted and require a significant amount of learn- 
ing and experience for optimum use. The 
effort required to identify and correct errors 
is minimized. A programmed instruction ap- 
plication program is specified to teach new 
users and is available at any time for review 
instruction during console use. The graphic 
capability and software controlled buttons 
and registers render the system ideal for this 
technique. 

A concept of order dependent parameter 
specification is employed in ambiguous cases 
to impart necessary meanings. The order in 
which parameters are picked determines how 
they are to be used when more than one way 
is possible. If two points are picked and the 
construction of a circle is requested, the first 
is the center and the second is a locus point. 
If the user forgets the order imposed mean- 
ing, he guesses and if wrong, erases and 
starts again. This avoids the necessity for 
parameter descriptor buttons for center, locus, 
end point, focus, vertex, radius, and axis. 
Table 4 shows all the allowed combinations 
and ordering of parameters to construct a 
circle. The numbers indicate order depen- 
dence, and X's indicate order independence. 
Combinations are read vertically. 
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rABLE 
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CIRCLE CONSTRUCTION 


PARAMETERS 


Point or X, Y Registers 


1 


X 


X 


X 


Point or X, Y Registers 


2 


X 






Point or X, Y Registers 
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It is impossible to specify too many param- 
eters for a construction because only the first 
set of meaningful parameters encountered are 
used in a last-in-first-used basis. Based on the 
first acceptable parameter encountered in this 
order, all other non-meaningful parameters 
are ignored. Table 5 shows several push-down- 







TABLE 5 




PUSH 


DOWN 


PARAMETER LISTS FOR 




CIRCLE 


CONSTRUCTION 




Toint 


(2)Toint 




Toint 


Tine 


Toint 


(l)*Point 




*Line 


Toint 


Toint 


Line 




Point 


Point 


*Line 


*Line 




Toint 


*Line 


Line 


Toint 




*Line 


Tine 


Toint 


Line 




Line 


Tine 


* Point 


*L Register 


Tine 


*L Register 


*L. Register 


Toint 




L. Register 
* Point 


Line 
Toint 









from-the-top lists for the circle construction. 
An asterisk indicates the chosen parameters. 

If there are not enough meaningful param- 
eters given when the construction is specified 
by a light button, "MORE" appears in the 
message register. Construction proceeds when 
enough parameters have been picked. Thus, it 
does not matter when the construction button 
is selected relative to the parameter picking 
in this case. 

Entities are constructed independently of 
the limiting frame of the working region. 
Thus, an entity can be constructed without 
appearing in the working region or it may 
only partially appear. An exception is, for 
open conies (hyperbola and parabola) only the 
arcs which lie inside the working region are 
created. Generally, arcs are constructed by 
creating the whole conic (in the working re- 
gion) and then picking the conic and end 
points as parameters to the arc construction. 

When three intersecting lines are used as 
parameters to construct a circle, several 
choices are possible: the inscribed circle tan- 
gent to the lines, the three exterior circles 
tangent to the lines, and the circle with the 
three line intersections on its locus. When a 
construction has been requested, one of the 
possible cases is displayed. The user must 
press the accept button to make the entity 
permanent, press the reject button to make 
it disappear, or press the alternate button to 
display another case for acceptance or rejec- 
tion. Only one case may be accepted for any 
one construction procedure. 

TRANSFORMATIONS 
AND CONSTRAINTS 
Transformations provided by the basic soft- 
ware and directly available to the console user 
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and application programs are: similitude (uni- 
form compression or expansion on a given 
point) , translation, and the linear, orthogonal 
transformations rotate and reflect. This pro- 
vides the user with the facility to change the 
scale of drawings or parts of drawings. Enti- 
ties and groups of entities may be moved, ro- 
tated, and reflected. Only one half of a sym- 
metric drawing need be drawn; and with the 
selection of a button, it may be reflected to 
produce the completed drawing. 

Semi-precision drawing can be done by im- 
posing constraints on freehand light pen 
usage. With the horizontal hold button de- 
pressed, the user can pick the tracking cross 
in the working region, and the drawing point 
normally traveling with the cross is con- 
strained to move in a straight line as the pen 
is moved at the angle specified in the base 
angle register. The vertical hold button and 
angle hold button work similarly, one normal 
to the base angle and the other at an angle 
specified by an angle register. The actual cre- 
ation of the straight line is accomplished by 
selecting a second button and accepting or 
rejecting that which is displayed. 

Animation is to be avoided when possible 
because of the computer time required to dis- 
play the intermediate positions of entities as 
they are transformed. A transform causes an 
original form to disappear and reappear in its 
final state. A transform-a-copy operation re- 
tains the original form and the new one 
appears. Animation may be valuable in cer- 
tain applications of dynamic design analysis 
such as mechanical linkage clearance study. 
This may be accomplished with application 
programs. 

DRAWING SURFACE 

While considering the transformations and 
data structure, it is logical to introduce the 
concept of the drawing surface. This is the 
two-dimensional, imaginary surface on which 
all graphics are described. It is limited in size 
and detail by the range of the number repre- 
sentation and precision of the computer. In 
engineering design applications involving the 
drawing of objects, the drawing surface is 
virtually unlimited in size and precision when 
the computer has a 48 bit word, floating point 
number representation. The working region 
of the CRT is used to view parts or all of the 
graphics on the drawing surface just as a 
variable magnification glass might be moved 



Over a map to view parts of it in detail. The 
zoom register, frame location registers, frame 
picking, and the translate transformation are 
used for this purpose. 

The drawing surface can be looked upon as 
an imaginary two-dimensional computer stor- 
age where the contents of specified X, Y loca- 
tions are points. The concept of drawing or 
subdrawing (groups of entities) relocatability 
is useful. Relocatability is simply defined by 
the translate transformation. A drawing may 
be stored in secondary storage such as mag- 
netic tape and located anywhere on the draw- 
ing surface. After it is brought into computer 
memory, it may be moved to a convenient 
location. A drawing overlapping another is 
not prohibited. It is important to keep in mind 
the distinct difference between moving graph- 
ics on the drawing surface and moving the 
working surface frame of view on the draw- 
ing surface. Both actions are performed using 
the translate transformation, but the graphics 
to be moved are picked in the former case, and 
the working surface frame is picked in the 
latter case. 

There is danger in loss of accuracy due to 
relocation. A drawing could be moved to a 
region of very high X and Y values and then 
returned to a region closer to the origin with 
complete loss of accuracy. Scaling could be of 
assistance, but it adds unnecessary complexity 
in most cases which can be kept under control 
by working close enough to the origin to main- 
tain required accuracy. A non-linear drawing 
surface might solve this problem without sig- 
nificant additional complexity, but it is not 
considered in this paper. Overflowing the 
range of the number representation is indi- 
cated as an error in the message register. 
However, modulo treatment of the number 
range makes the drawing surface cylindrical 
in X and independently cylindrical in Y. 

DRAWING SCALE 
Drawing scale is normally an unnecessary 
consideration except when hard copy output 
is being prepared. Drawings are usually made 
in actual dimensions without any difficulty 
because of the vast range of the drawing sur- 
face as compared to the real world of objects 
to be drawn. The zoom function changes the 
scale of drawings, but only for visual purposes 
on a temporary basis which does not affect 
the data list. When a drawing is to be output 
in hard copy form, the user must change the 
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scale of auxiliary views with the similitude 
transformation as needed, add scaling notes 
to the drawing, and indicate the scale to be 
used by the output program. 

PRINTING 

Alphameric printing capability deserves an 
important place in a graphical system. Engi- 
neering drawings can contain very large vol- 
umes of notes, labels, and dimensions. Print- 
ing capability is provided in the form of a 
raster of alphamerics displayed in the control 
region. The . procedure consists of picking a 
starting point, picking an angle if other than 
the base angle, and then employing a hunt- 
and-pick mode of character selection, all done 
with the light pen. Associated light buttons 
are also needed for margin control, font selec- 
tion, and roll-up or roll-down carriage return. 
All characters are placed in a single text en- 
tity until an end text light button is selected. 
The alphameric raster is displayed in the con- 
trol region only when selected by a keyboard 
button, and it disappears when the end text 
light button is selected. Erasure is done at 
the character level by the erase function. Nu- 
meric information is put into a picked light 
register from the right end and shifted left 
for each new digit or decimal point selected. 
The sign is entered independently in a fixed 
location. 

There are several advantages to this type 
of software provided printing feature in con- 
trast to a hardware keyboard. Advantages 
include economic savings in hardware, re- 
duced maintenance problems, and increased 
console reliability. There is also an advantage 
in its use. All of the user's attention remains 
on the CRT and light pen. He does not have 
to put the pen down and turn to a keyboard. 
Printing and drawing graphics are highly 
intermixed in design making it an advantage 
for the two types of operations to be com- 
patible. 

DRAWING AIDS 
Additional drawing aids are available in 
a separately maintained subroutine library. 
Light buttons are provided by the basic soft- 
ware to select them. 

1. Display the intersection (s) of two entities. 

2. Create a general conic arc given one of the 
following sets of five parameters: five 
points; four points and a tangent angle at 



one of the points ; and three points and tan- 
gent angles at two of the points. 

3. Create a curve of one or more conic arcs 
which is approximately parallel to a given 
conic and a distance ±D from it. The maxi- 
mum error is displayed. 

4. Compute the length of a conic or conic arc. 

5. Display a point on a conic a given distance 
from a given point. 

6. Compute the tangent angle at a point on 
a conic. 

7. Display a straight line segment from a 
point to a conic and tangent to the conic. 

8. Display a straight line segment tangent to 
two circles. 

9. Construct a circular fillet given a radius 
and two line segments sharing a common 
end point. 

Numeric results are also put into light 
registers. Order dependence is used exten- 
sively. When multiple results are possible, the 
user may select any or all by button control. 
Errors, input deficiencies, non-existence of 
results, and results off the working region or 
drawing surface are indicated in the message 
register. 

CALCULATOR 

An additional basic software feature is desk 
calculator-type capability. The basic oper- 
ations including square root, multiply-add, 
and multiply-subtract, are handled by light 
buttons. The operand registers and result 
register are picked in an order-dependent se- 
quence followed by selecting the operation 
which causes the action to be performed, all 
done with the light pen. 

Additional functions including logarithmic, 
exponential powers, trigonometric, and fre- 
quently used constants are also easy to supply 
in light button form. The calculator set of 
light buttons is a good example of a control 
region feature which is not needed at all 
times, but can be displayed under control of 
a keyboard button when needed; thus con- 
serving both control region space and CRT 
beam control instructions. 

MACRO 

One of the more annoying console oper- 
ations is performing the same sequence of 
operations very frequently. The normal con- 
sole features are micro in nature to provide 
flexibility. Application programs can be writ- 
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ten to provide automatic execution of sets of 
operations, but not as easily and quickly as 
sometimes needed. A drawing aid subroutine 
is provided with which the user may define 
macro console operations as he needs them 
from sequences of basic operations. 

The sequence of operations to define and 
use a macro follows : 

1 . Pick the input parameters. 

2. Select the macro definition button. 

3. Select two characters and place in a box to 
be used as the macro button. 

4. Step through the sequence of operations to 
be defined. 

5. Select the macro definition button to termi- 
nate the definition. The box disappears leav- 
ing the macro button displayed. 

6. The macro may now be used by picking the 
appropriate parameters and selecting the 
macro button. 

Note that no parameters may be picked 
intermediate to the macro operation. When 
this is required, several macros must be de- 
fined and used in sequence and separated by 
parameter picking. 

An example shows the usefulness of this 
feature. A copy of a template pattern such as 
a standard screw (represented by a group of 
entities in a standard template drawing on 
the drawing surface) is to be placed at the 
proper angle into the drawing under construc- 
tion. A point at the base of a screw head is 
picked, the point of final position in the draw- 
ing is picked, and another point is picked such 
that the angle defined by the last two points 
is the desired angle for the screw centerline. 
The macro define button is selected, and the 
letters SC are placed in the macro button box 
in the control region. The operations perform- 
ing the translate-a-copy are now performed. 
The first picked point is picked again to cause 
the whole group defining the screw to be 
picked, the X, Y registers containing the 
coordinate values of the second point are 
picked, the copy of the screw is moved to over- 
lay the translate parameter points, the copy of 
the screw and the last two points are repicked, 
and the screw is rotated through the required 
angle. The macro define button is selected to 
complete the definition. A copy of any group 
of entities may now be moved and rotated by 
picking the three prescribed points in order. 



INPUT AND OUTPUT 
Input and output between secondary mass 
storage and the computer memory (drawing 
surface) for temporary and permanent stor- 
age is accomplished in the basic software by 
using a two file system. A permanent file of 
drawings is available to the user based on 
drawing titles. The file is updated only by an 
editing program from the second file called 
the working file. Each console user has his 
own working file in which are stored refer- 
ence drawings, partially completed drawings 
and, possibly, drawings awaiting approval for 
transfer to the permanent file. A region of 
the drawing surface is reserved for a list of 
the names of the drawings in the work file. 
An arrow points to the name of the first or 
last selected drawing. The arrow may be 
moved by the light pen to a name of a draw- 
ing, selection of a light button causes the 
drawing to be deleted or placed in the com- 
puter (on the drawing surface). New names 
are added automatically as drawings are filed 
by the user. Hard copy of drawings may be 
produced on paper, microfilm, or other media 
by one of many available plotter or microfilm 
systems now on the market. Configurations 
may include systems on-line, off-line, and re- 
mote or adjacent to a console. One objective 
of the system is to minimize the desire and 
need for hard copy by making the consoles 
inexpensive, easy to use, and readily available. 

APPLICATIONS INTERFACE 

The most important software feature is the 
applications interface which makes the sys- 
tem a design tool and problem solver, not just 
a drafting machine. It consists of an execu- 
tive application call routine and a set of 
FORTRAN subroutines. The purpose is to 
provide the data list and all the system fea- 
tures, except light pen tracking, in a form 
easy to use in FORTRAN application pro- 
grams. All application program activity is 
carried out through the interface in a rela- 
tively non-changing environment to minimize 
the need for recoding programs when basic 
software changes are made. There are two 
distinct interface functions. One allows an 
application program to perform all functions 
available to a user, in the same way, except 
pen tracking which has no meaning to a pro- 
gram. A program may pick parameters, fill 
registers, select light buttons and, effectively, 
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push keyboard buttons. In addition, the program 
may inhibit the use of most console features, 
change their meanings or, in the case of con- 
trol region features, change their positions 
and add new ones. Finally, a pause-until- 
console-action function provides an interrupt 
before or after action making the application 
program operable in the console user's real 
time. These features combine to provide a 
close working relationship between the user 
and computer, allowing the best characteris- 
tics of both to be brought to bear on problems. 
A master switch allows the user to turn off 
the application and return control to the con- 
sole. This capability is unalterable by an 
application program. 

A practical application program using this 
first function of the interface is one which 
records every action taken by the user in a 
time history. It produces a printed list nam- 
ing each action and the time taken by it. This 
is most valuable in studying the man-machine 
interaction to make improvements in the sys- 
tem and to evaluate the skill and difficulties 
of the user. 

The second interface function provides fea- 
tures more suitable to programming. These 
include routines to translate and include 
program-generated entities into the data list, 
to search the data list for entities based on 
any combination of characteristics, and to use 
the entity construction and manipulation fa- 
cilities without going through the external 
console. For example, a call to the intersection 
subroutine with two entity relative addresses 
as parameters would return the intersection 
points as values assumed by a second pair of 
parameter names in the calling statement. 

The system becomes a versatile tool with 
this capability. Many existing programs run 
in a batch mode computer operation can be 
fitted with preprocessors and postprocessors, 
thus, adapting them for on-line graphics capa- 
bilities. 

Another important program executed out- 
side the system provides a data structure and 
language translation for input of graphics to 
work files from handwritten coded sheets via 
punched cards. 

Application programs are brought into 
memory from secondary storage by the execu- 
tive application call routine at the request of 
the console user. An application program is 
executed until ended, until an interrupt for a 



high priority console request is received, until 
a pause statement is executed, or until a time 
limit expires. If control is to be returned to 
the application at a later time, it is kept in 
memory, or it is temporarily dumped into 
secondary storage, preserving its current state 
when memory space is needed. 

APPLICATION EXAMPLE 
A concise application demonstrating many 
of the system capabilities is the calculation of 
the area and centroid of a closed polyconic 
forming a simply or multiply connected do- 
main and/or a system of dot-area centroids. 
The program steps and algorithm are as fol- 
lows: 

1 . The randomly ordered, user picked entities 
describing the simply or multiply connected 
domain and/or the dots each followed by 
its associated area value are accepted. 

2. A closure check is made. If lack of closure 
is discovered, the unconnected end points 
are displayed in small triangles and 
"MORE" appears in the message register. 
The user may press the reject button, in 
which case, the displayed triangles and 
message disappear and the program termi- 
nates. The user may also pick one or more 
entities which complete the closure, in 
which case, the triangles and message dis- 
appear and step 2 is repeated. If only a 
single closed conic has been chosen, the 
centroid is set to be the center point, and 
the area is calculated by standard formula. 
Go to step 8. Step 2 is ignored if all param- 
eters are dot-area centroids. 

3. Divide each double valued entity in X into 
two single valued entities. Discard vertical 
straight line segment entities, and divide 
straight line segment string entities into 
straight line segment entities. 

Y=F j (G,X,XY,S),X 1 < X < X 2 , 
j = l,2,...p 

are the p remaining entities where G is the 
geometric descriptor taking on one of the 
values: straight line segment, horizontal 
straight line segment, circle arc , elli pse arc, 
parabola arc, or hyperbola arc. XY is a set 
of fixed coordinate points, S is a set of 
scalars, and X t and X 2 the X coordinates 
of the end points. Thus a circular arc with 
center at h, k, radius R, and end points 
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at X lt Y 1 and X 2 , Y 2 (X ± < X 2 ) would be 
represented by the equation 



Y = k - y R 2 -(X-h) 2 ,X 1 < X<X 2 

where the sign of the radical was chosen 
negative because X x < X 2 and X x , Y 1 is 
the beginning point of the arc in a counter- 
clockwise direction. 

|x c , Y c , A c l j, i=i, 2, ..., L 

are the dot-area centroids. 

4. Divide the range of X, from smallest to 
largest encountered, among the end points 
of the p entities into subranges of X so that 
all end points of entities lie on subrange 
boundaries. 

Xt <X 2 «<X 8 <,...< x n> . 

Xj, i=l, 2, . . . , n are all the distinct co- 
ordinate values of end points of the p enti- 
ties. 

5. In each subrange, order, from the highest 
to lowest Y values, the entities included in 
that subrange by highest Y value each en- 
tity assumes in that subrange. 



h 



i > Fj 



J2 



F 



jm j 



Max(Xi, X i+1 )Fj k >Max(Xi, X i+1 )F jk+1 

for the m entities in the subrange Xj, Xj-j-! 
and for each i, i=l, 2,. . .,n-l. Note that if 

Max (Xj, X i+1 )Fj =Max (Xj, X i + 1 )Fj k+1 , 

it must be at Xj or X{-\- t for p > 2. If this 
is the case, say at Xj, then the ordering is 
based on Fj k (X i+1 ) > Fj k+1 (X i+1 ). 
For p=2, it is based on 



Fj 1 (X 1 + 



X 2 X ± 



)> Fj 2 (Xi + 



X 2 — Xi 



). 



6. Working from smallest to largest values of 
Xj and largest to smallest values of Y, com- 
pute contributions to the total area and 
first moment using the appropriate alge- 
braic expressions which are based on the 
geometric property of each entity. Area 
contributions come only from alternate 
regions bounded by the X subrange bound- 
aries and ordered entities in pairs. This 
correctly chooses the inside area contribu- 
tions. The area and moment equations are 



derived analytically from the definite in- 
tegral equations. (This is a tedious but 
straightforward task.) 
n-i x i+1 

Area =J] J [vi^-...*^.^] « 



i=l X< 
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n-1 X. 
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ci 



i=l 



X c = Moment/ Area 

where X c is the X coordinate of the 

centroid. 

7. Step 3 through Step 6 are repeated inter- 
changing X and Y. 

8. The centroid point is displayed contained in 
a small box, the X, Y values of the point 
are placed in the X, Y registers and the 
properly scaled X-calculated area and Y- 
calculated area are stored in the second set 
of X, Y registers. "Reject/ Accept" is put 
in the message register. 

9. The user may push the accept button, the 
point is made a dot, the box and message 
disappear, and the program terminates. If 
the user presses the reject button instead, 
the point, box and message disappear, but 
the contents of the X, Y registers are not 
changed, and the program terminates. 
During steps 1 through 7 the message regis- 
ter contains "Computation Proceeding". If the 
parameters chosen are limited to point-area 
centroids instead of closed polyconics, then 
the program computes the centroid of the sys- 
tem of these centroid points. 

CONCLUSIONS 

The major limitation of the graphic system 
is that the software would be highly complex 
and extensive which, like APT Systems, is 
costly to produce. Use of standard program- 
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ming languages and isolation of required basic 
machine language subroutines will minimize 
this problem. 

The volume of data required to represent 
graphics in visual form is very high requiring 
large, cheap storage systems. This is especially 
true when mathematical capabilities are im- 
plemented for processing of higher degree 
curves and three-dimensional curve and sur- 
face perspective projections into two dimen- 
sions in a general way. There is expected to 
be an extensive evolution of console and appli- 
cation program features as graphic systems 
come into general use. For this reason, modu- 
larity in software implementation and large 
amounts of financial resources will be needed. 
It is expected that the potential revolutionary 
effect of graphic systems on design activities 
will justify such expenditures. 

Although this system as partially described 
here is idealized and not implemented, many 
of the features will be realized in systems 
being planned and in development at the Digi- 
graphic Laboratories and other facilities of 
Control Data Corporation. 

It is believed that the goals of this graphic 
system are met to a great degree by the fea- 
tures described. It is a practical system in 
that all the features can be implemented 
within the current technological state. Power- 
ful features are found in the macro capability, 
the data structure and grouping capabilities, 
and in the potential power of the application 
interface. Economy is found in the relatively 
simple console hardware and in emphasis on 



minimization of the computer time required. 
Sophistication is found in the use of order 
dependent operations, macro availability and 
potentially in applications which can be easily 
included in the system. These last mentioned 
features make the system easy to use on its 
simplest level, but a challenge to the imagina- 
tive and strongly motivated person. 
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Dr. David A. Pope* 



On-Line Scientific Applications 



CONCEPTS OF ON-LINE COMPUTING 

One of the most interesting recent develop- 
ments in computing is the on-line concept of 
rapid interaction between the digital com- 
puter and the user. This development has im- 
mediate application in the area of scientific 
computing, particularly in those problems 
which might be characterized as research 
computations, rather than production comput- 
ing. In the former type or problem, very often 
the specific algorithms to be used in the nu- 
merical solution are unknown, and a major 
part of the problem is to find a reasonable set 
of such algorithms and to demonstrate that 
they do, indeed, work for the specific problem. 
In this effort, the possibility of a dialogue 
between the user and the computer presents 
some real advantages. 

An on-line computing system in this context 
might be characterized in the following way. 
Access to the computer should be immediate, 
at least on the user's time scale. In practice, 
this means a delay never exceeding a few 
seconds, and usually less than 0.1 second. The 
results of a computation should be available 
immediately, and in a form easy for a human 
user to comprehend. Finally, the program- 
ming should be easily modifiable so that 
changes in the algorithms can be made quickly, 
on the basis of intermediate results. 

The computational requirements both for 
the problem being investigated and for the 
software package necessary to implement the 
on-line system mean that a digital computer 
of moderate to large size is involved in the 
system. This means that, for economic reasons, 
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most on-line computing systems will need to 
have the large central computer shared by 
several users ; thus some kind of time sharing 
scheme must be provided which does not con- 
flict with the immediate availability require- 
ment above. Therefore we are led to the con- 
cept of a central computer provided with a 
number of time shared user consoles, each 
console provided with convenient input-output 
devices. 

THE CULLER-FRIED APPROACH 
TO ON-LINE COMPUTING 

One such approach is the on-line system 
developed by G. J. Culler and B. D. Fried 1 . In 
this system the user is provided with two type- 
writer keyboards for input, and a storage CRT 
for output. The data is presented to the user 
and computed functionally. That is, the basic 
unit which the user manipulates is a single 
real or complex valued function, which is rep- 
resented in the computer by a pair of vectors 
of up to 125 points each. The output CRT dis- 
plays a pair of vectors as a set of point pairs 
(xj, yj), j = l, 2, . . . 125, with the adjacent 
points (xj, y,-) and (xj-\- lf yj + i) connected 
by a straight line. This gives the appearance 
on the CRT of a smooth curve, which may be 
interpreted as a real valued function, or as a 
curve in the complex plane. One typewriter 
keyboard is used for the designation of storage 
addresses, each address being given by a 
number and a letter, such as 1A, 3F, etc. This 
keyboard is also used for typing alphanumeric 
information on the display CRT. 

The other keyboard is used to designate 
operations on the functions. On the basic 
levels, the computer can be operated as a glori- 
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fied desk calculator. The arithmetic operations 
add, subtract, multiply and divide are supple- 
mented by the commoner mathematical func- 
tions such as square root, sine, cosine, log- 
arithm, exponential, forward difference, and 
sum. Each operation key, when depressed, 
initiates a subroutine in the computer which 
performs the operation on the entire function. 
To supplement these, there are also operations 
to load and store functions, and to display one 
or more functions on the CRT. Thus the user 
can manipulate functions, displaying the re- 
sults instantly whenever a display is wanted. 
As an example of this, we may take the gen- 
eration and display of the function 

y = e~x/ 2 , 

for —1 < x < +1. The operation keys to be 
depressed would be : J-generate, square, divide, 
—2, exponential, store, 1, E, display, 1, A. The 
J-generate is an operation which generates the 
standard linear function y=x, for 
— 1 < x < + 1. This function is then squared, 
divided by the constant function —2 (entered 
by numerical keys on the operation keyboard), 
exponentiated, stored in location IE, and then 
displayed on the CRT. 

However, this system would be of limited 
usefulness without some method of conveni- 
ently building up more complex algorithms 
from the simple ones provided. This is done by 
using the concept of console programming. A 
special program key is provided which, when 
depressed, puts the computer in a program 
writing mode. While it is in this mode, a list 
is formed of any keys depressed, and this list 
is assigned to a chosen vacant key. Thereafter, 
whenever the chosen key is pushed, the com- 
puter automatically pushes the entire list of 
keys which was assigned to it. Furthermore, 
one key on the list may itself be a programmed 
key, and call on a sublist of operations. This 
is done, of course, by automatically providing 
appropriate linkages between the basic sub- 
routines. 

Thus, by nesting subprograms, a single key 
may be constructed to perform an algorithm 
of almost any complexity, involving perhaps 
thousands of operations. In this way, the full 
power of the digital computer can be utilized, 
and yet controlled and monitored in detail by 
the user. This idea also simplifies the modifi- 
cation of programs by the user, since any pro- 
grammed key, being a subroutine, can be 
changed without modifying the program of 



which it is a part, and without influencing 
programmed keys which went to make it up. 
In this way, a user can explore his problem, 
making up and discarding programs, while 
watching the results of his computation on 
the CRT. A computing algorithm will thus 
evolve which will solve his problem, or else 
perhaps enough will have been learned about 
his behavior so that it can be reformulated 
and a fresh attempt made. 

EXISTING CULLER-FRIED 
ON-LINE SYSTEMS 
The Culler-Fried system, as described above, 
was first developed at the TRW Canoga Park 
facility, and a two station prototype system is 
now there, using one RW 400 computer for 
each console, with no time sharing. An ad- 
vanced model is currently being delivered to 
TRW/STL in Redondo Beach, which will have 
four consoles, time sharing one RW 340 com- 
puter. Also a Culler-Fried system similar to 
the prototype system is being developed at the 
UCLA Computing Facility, which uses the 
IBM 7094. At present the UCLA system has 
one console and ties up the 7094 completely, 
but in a few months it is planned that the 
Culler-Fried system, along with other on-line 
systems such as the PAT language will share 
the 7094 memory together with standby 7094 
problems, and the on-line computation will be 
done on an interrupt basis, but without the 
necessity of exchanging memory. 

KINDS OF PROBLEMS AMENABLE TO 
THE CULLER-FRIED APPROACH 

Various problems have been tried on the 
prototype system in Canoga Park for approxi- 
mately two years. The problems for which this 
computing system is particularly suited may 
be characterized as "fixed point" problems in 
a function space. That is, a function f is 
thought of as an element or "point" in a set of 
functions, or function space. There is, in this 
type of problem, an operator T on the space, 
which maps the function space into itself, and 
the problem is to find a function f which is 
"fixed" under T ; that is, f satisfies the equa- 
tion T[f] =f. A simple example of this kind of 
problem is the solution of an ordinary differen- 
tial equation y f —i (x, y) with initial condition 
y(a)=b. If this is written in integral form, 
we have * x 

y (x)=b+ / f (t,y(t))dt 
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We identify the integral operator T as 
T[y]=b+ f\ (t,y(t))dt 

and we have the problem expressed in the 
fixed point form T[y] =y. The Picard iteration 
for the solution can then be written 

y n+1 =T[y n ], 

yielding successive guesses y lf y 2 , . . . from 
an initial guess y . Other problems with essen- 
tially this same structure are found in partial 
differential equations, calculus of variations, 
integral equations, control theory, and other 
mathematical and physical problem areas. 

Given such a formulation of a problem, the 
problem analyst uses his experience to set 
up algorithms for solving the fixed point prob- 
lem, usually with some iterative scheme. It 
becomes immediately apparent during the 
computation whether or not the algorithm is 



converging and, if it is not, just where the 
difficulty lies. This information is then used 
by the analyst to revise the algorithm and try 
again. In practice it is found that a great deal 
of insight into his problem can be obtained by 
a skilled user. 

One of the most significant advantages of 
this type of on-line system, in fact, seems to 
be that the human user of the computer does 
not need to be a computer expert, or indeed to 
know very much about computers. What he 
does need to know is that area of mathematics 
and numerical analysis which is involved in 
his problem. The role of the computer is to do 
the tedious work, including the tedious pro- 
gramming bookkeeping, and free the problem 
originator to think about his problem. 



REFERENCE 
1 G. J. Culler, B. D. Fried, and D. A. Pope, "The TRW 
Two-Station, On-Line Scientific Computer", TRW/ 
STL Physical Research Division Report 8587-6002- 
RU-000, Vols. II, III, IV, July 1964. 



104 



Dr. R. B. Talmadge* 



Structuring Compilers 
for On-Line Systems 



INTRODUCTION 

Recently a number of systemsf have been 
produced for on-line operation of a computer 
job shop which have aimed at improving user 
productivity by allowing continuous man- 
machine interaction, while at the same time 
preserving compatibility with previous sys- 
tems. Most of these have employed modified 
versions of compilers written for a batch 
processing environment. As might be ex- 
pected, the internal techniques used for 
handling multiple input strings, especially re- 
source sharing techniques such as multipro- 
gramming and program commutation (time 
sharing) , conflict with the single string orien- 
tation of the original implementation. In par- 
ticular, the program segments themselves, and 
the intermediate data retained, are much too 
large; so that system response is degraded 
because of wasted blocks of core and excessive 
swap times. 

Most of the proposed remedies, such as in- 
core compilers, and the use of read-only code, 
while salutary, apply equally well to any pro- 
gram operating within that envoronment. The 
question naturally arises as to whether dis- 
tinctly different principles of organization, as 
contrasted to techniques of mechanization, are 
desirable. This in turn leads to consideration 
of the compiler as a system component, to its 
role in the relation between system and user, 
and to the question of how much compiler 
design is influenced by the process one wishes 



to optimize (in whatever sense that word is 
being used). 

It is the purpose of this paper to suggest 
that a critical examination of the overall 
objective of the compilation process leads to 
an organization founded on the requirements 
of providing optimal user/system interaction ; 
that this structure is, to a large extent, inde- 
pendent of internal techniques ; and that past 
experience will therefore prove a valuable 
guide to future development. 

USER/SYSTEM INTERACTION 

The basic starting point in this exploration 
is the functional relationship between user 
and system. This is outlined in Figure 1, which 
illustrates the paths of information flow, and 
the functions involved. For the system, these 
functions are compilation and execution; for 
the user, formulation, modification, and check- 
out. Interaction then occurs in the following 
way. 

1 . The user's original formulation of his prob- 
lem in some source language, or combina- 
tion of source languages, is entered into the 
system through the compiler. 

2. At some point in the course of the compila- 
tion, misuse of the language is detected. 
Information is returned to the user which 
causes him to modify the original formu- 
lation. 

3. When the modified formulation seems sat- 
isfactory to both user and system, the prob- 



fThree well-known examples are discussed in refer- 
ences 1 - 5 and 8 . 



"Manager, Experimental Systems Group, Los Angeles 
System R&D Department, IBM. 
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FIGURE 1 

USER/SYSTEM INTERACTION 



lem proceeds to execution. As a result, in- 
formation is generated which leads the user 
to produce further modifications, and 
statements intended to help check out the 
program. 
4. Eventually (it is hoped) execution is suc- 
cessful, and the program is considered op- 
erational. 

It is important to realize that this process 
is essentially the same irrespective of the 
number and timing of the interactions, and 
the rate of information flow in the data paths. 
The picture is not affected, for example, 
whether or not compilation proceeds to a 
nominal end before messages are conveyed to 
the user, or whether execution is interruptable 
immediately upon the occurrence of some 
unforeseen condition. Thus, although an opti- 
mal system involves some compromise between 
minimizing the number of iterations of the 
process, the time per iteration, and the cost of 



the equipment, there is firm reason to believe 
that certain structural principles remain in- 
variant to any adjustment. 

This discussion, of course, covers only a 
portion of the actual system. To the user, 
however, it is the most important part ; indeed, 
it is virtually the only part. For the term 
compilation, as used here, represents the 
entire program preparation activity. So that 
a compiler is a system processor, primarily a 
language processor, whose function is to turn 
the user prepared formulation of his problem 
into a form suitable for use within the hard- 
ware-software complex. This is an enlarge- 
ment, perhaps, of the traditional notion of 
compiler, but it is pertinent to the course of 
the discussion. As a complement to this, the 
term execution is used to represent the carry- 
ing out of the intent of the formulation ; that 
is, the actual performance of the stated algo- 
rithms. 
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Thus the interface between compilation and 
user is fixed, as determined by external con- 
siderations ; the interface between compilation 
and execution is variable. As will be seen later, 
adjustment of this interface can be used to 
improve the overall operating efficiency. To 
see how this is possible, to get an idea of the 
minimum point to which compilation should 
go and the maximum beyond which it should 
not proceed, it is necessary to make a closer 
examination of the user functions (Figure 1). 

Formulation. Although the mechanics of formu- 
lation may be rather complicated, interface 
with the system reduces to expressing the 
problem in processing languages. For this dis- 
cussion interest centers not in the details of 
a particular language, but in characteristics 
observable of programming language usage in 
general. The important point is that the num- 
ber of problem oriented languages in use today 
is large, and the number of dialects within 
these languages is even larger. This trend is 
not likely to be reversed however much one 
might wish to the contrary. Linguistic expres- 
sion is rather personal, so that users tend to 
specialize in forms which suit their tempera- 
ment as well as their particular class of prob- 
lems. Furthermore, even if one were to pro- 
duce a language capable of expressing all data 
processing activity, balkanization would occur; 
not especially out of pertinacity, but because 
user efficiency is enhanced by languages which 
permit simple and clear expressions of the 
problem. Therefore, it is really the responsi- 
bility of the compiling portion of the system 
to handle a variety of languages ; and to do so 
in such a way as to permit easy intercourse 
between them. 

At the same time, it remains a fact that 
processing requirements are much the same 
for large classes of problems. Hence, under- 
neath their obvious differences, problem ori- 
ented languages fall naturally into families 
whose members express virtually the same 
functional capability. An outstanding example 
of this is that class whose most well known 
members are FORTRAN, COBOL, and AL- 
GOL. 

Modification. There are two ways that modifi- 
cations to existing programs are done in 
current systems, depending upon the facilities 
provided, and the preference of the individual 
user. First, changes may be expressed in mod- 
ification units which are independent of the 



content of the program. A common method, 
for example, is the ALTER mechanism for 
replacement, insertion, or deletion in card 
record files. Second, changes may be expressed 
in terms of the content of the program; that 
is, in units depending upon the formal syntax 
of the source language. For instance, a par- 
ticular symbol in the program might be re- 
placed, or a string of characters inserted at 
some arbitrary point. For maximum use and 
flexibility, the compiler must find a simple 
way of reconciling these two distinct types of 
procedure. 

Checkout. Checkout embraces all activity re- 
quired to obtain a correct program statement, 
from detection of misuse of the language to 
debugging the logic of the problem. The 
former is clearly the province of the compiler. 
As for the latter there are two points of view. 
Some users regard debugging as a general 
problem which should be handled in a general 
way. If this principle is adopted, it leads to 
the formulation of a separate debugging lan- 
guage, and so to another language responsi- 
bility for the compiler. On the other hand, 
some prefer to use statements in the original 
source language; and hence to use one of the 
two modification methods to insert the debug- 
ging requests. In either case, the volatile 
nature of these changes requires that they be 
inserted at a point which is effectively beyond 
the permanent information retained by the 
system. 

Most important, however, is that changes, 
whether permanent modifications or tempo- 
rary debugging statements, should be on an 
incremental basis ; that is, should not require 
the entire resubmittal of the program. Reduc- 
tion in the amount of superfluous data trans- 
mitted between elements of the complex is 
the biggest single factor in obtaining superior 
performance from both user and system. 

FIRST PHASE OF COMPILATION 
These considerations, which obviously apply 
to any system, lead naturally to the expecta- 
tion that the convergence of function for a 
related family of languages can be profitably 
paralleled by a similar convergence in the 
compilation process ; and hence, that the first 
phase of compilation should be the production 
of a standard program representation, free of 
external irregularities, and permitting easy 
incremental modification. This is, in fact, the 
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method adopted in most recent compilers? It 
results in a functional organization like that 
illustrated in Figure 2. 

1. The source languages of the family are 
treated by individual conversion processors 
to produce a primary (internal) represen- 
tation of the program. 

2. Errors detected by these processors are 
sent to the user by whatever means are 
natural for the system. In an off-line sys- 
tem, for example, they would be collected 
and dispatched as a group. In an on-line 
system, with the user at a responsive input 
device, they would be sent immediately, as 
individual messages leading to possible in- 
tervention. 

3. In either case, the resulting modifications 
are handled by a modification processor 
which replaces individual statements in the 
primary representation. 



*Such as 7090/94 IBCBC (IBM), 1107 FORTRAN 
(Computer Sciences Corporation), and QUIKTRAN 
(IBM). For an excellent discussion of the primary 
representation used in the last of these, see refer- 
ence 4 . 



4. Similarly, debugging statements which the 

user generates as a result of execution are 

passed through the debugging processor. 

Of course, the modifications and debugging 

processors, which are shown in the diagram 

as separate from the conversion processors 

because they represent separate functions, 

would, in practice, be entirely absorbed in 

them. 

As for the conversion processors them- 
selves, their functional capability is delimited 
by the properties and information desirable 
in the primary representation. Some of these 
can be fairly clearly established at this time. 
First, since the representation is to be free of 
language errors, conversion must, at least, ac- 
complish a complete lexical and syntactical 
analysis of the program. Second, as the repre- 
sentation contains all the symbolic informa- 
tion of the original, and serves as the basis for 
modifications, it must contain explicit markers 
for modification units and be structured so as 
to facilitate these changes. This puts an upper 
limit to the amount of processing which can 
be done in conversion. For, since even the 
simplest external change can have profound 
effects on the meaning of a program, it is ex- 
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ceedingly wasteful to attempt any instruction 
generation, or even to make tentative attempts 
at optimizing execution efficiency. At the same 
time, good practice dictates that as much in- 
formation as will be useful should be col- 
lected from the program string as it is con- 
verted, and placed in a form most suitable for 
later processing. Hence the representation will 
consist of, and the conversion processors must 
produce, some combination of lists, tables and 
formal expressions which display the explicit 
structure of the program (particularly loops 
and transfers), the usage of symbols, and the 
characteristics of the data; and facilitate the 
functions of optimization, instruction genera- 
tion, and (as will be seen) direct execution. 
Of the many advantages of this organization, 
the following are probably the most note- 
worthy. 

1. Production of the primary representation 
effectively isolates the external world from 
the interior of the complex. This makes a 
substantial part of the system immune to 
language changes, emendations, and ad- 
ditions. It also permits the introduction of 
a new language into the family by simply 
constructing another conversion processor, 
most of whose pieces are already available. 

2. Retention of the primary representation 
within the system as the permanent sym- 
bolic form of the user's program permits 
additional useful services to be supplied, 
as well as providing the user with the oper- 
ational convenience of handling small vol- 
umes of data. Special system processors 
can be easily designed to exploit the precise, 
explicit information available. A natural 
one, for example, would be a flow charting 
program. 

3. Data flow is, of course, drastically reduced. 
Further efficiency is obtained because re- 
compilation starts from an advanced base: 
an appreciable fraction of the work of 
compilation is expended in the data gather- 
ing and syntactic analysis of conversion. 
This, in effect, gives a specific meaning to 
the somewhat loose term incremental com- 
piling (and probably the only sensible one). 

There are thus persuasive reasons, dictated 
by general considerations of user convenience 
and overall efficiency, for adhering to the 
structure so far described. It is, therefore, of 
some interest to turn to the systems functions 
to see if these reasons are reinforced ; and, if 



so, to determine how much can be deduced 
about the structure of the rest of the compiler. 

DIRECT EXECUTION 
With the basic statements of the program 
resident in the system in internal form, the 
next step is to consider the boundary separat- 
ing compilation and execution. The primary 
factor influencing adjustment of this bound- 
ary is the desire to attain a favorable resolu- 
tion of the inevitable conflict between service 
to the individual user and service to an entire 
group of users. Here, for the first time, a dis- 
tinct difference becomes apparent between an 
off-line system and a responsive on-line 
system. 

In the latter case, there are a substantial 
number of programs for which the overall 
efficiency will be markedly improved by direct 
(interpretive) execution from the primary in- 
ternal representation. This arises for the fol- 
lowing reasons: 

1 . There are a number of jobs in any instal- 
lation which are processed repeatedly by 
the compiler, and (partially) executed 
many times solely for the purpose of exe- 
cuting correctly once. Examples abound, 
but the most obvious ones are student prob- 
lems at universities, and the desk calcu- 
lator type so common in the open shop 
installations of the aerospace industry. On- 
line systems are, of course, aimed directly 
at this class of personal computing* Direct 
execution can significantly reduce the total 
effort by bypassing much work that is ordi- 
narily wasted in compiling, re-compiling, 
and executing incorrect instructions. For 
in this mode of operation, the immediate 
availability of debugging information, in 
fact the absolute necessity of supplying 
error information which the user could not 
have anticipated he would need, together 
with his presence on-line, cuts short the 
execution of most unwanted sequences. 

2. One of the touted advantages of an on-line 
system is the use of the computer as an 
intelligence amplifier. In this form of oper- 
ation the user designs his program as he 
goes along, presumably building on the re- 
sults of previous (partial) executions to 
decide what to do next. Direct execution 
supplies a convenient, readily available tool 

* To use the apt classification of R. L. Patrick 7 . 
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for conversational interaction between pro- 
gram and user. Furthermore, even though 
such programs are undebugged almost all 
the time, the interpreter is in full control 
and so supplies automatic protection for 
other programs concurrent in the system. 
Errors which occur result in messages to 
the individual user without requiring sys- 
tem interruption. The resultant reduction 
in overhead tends to improve overall effi- 
ciency and maintain satisfactory response 
times. 

None of this applies to a batch processing 
system because the real advantages of the 
direct method (which still exist) are nullified 
by the temporal length of the communication 
paths, and the right granted every program 
to exclusive use of the machine. 

Nevertheless, however well suited direct 
execution is for some problems, there are 
others, more numerous in most installations, 
for which the necessity of repeated high level 
interpretation is a serious drawback. Even 
the least experienced user can, and will, write 
programs for which this would become a 
problem for him : programs, for example, with 
loops traversed many times, programs which 
once checked out are to be used repeatedly ; or 
programs so large as to overstep reasonable 
limits for interpretation. 

These considerations are reflected in current 
responsive on-line systems, which exhibit a 
complete dichotomy of attitude. On the one 
hand, systems which encourage the user to 
build his programs on a piecemeal basis are 
dedicated to a particular language and are 
fully interpretive.* On the other hand, com- 
patible systems provide for interpretation only 
as a user program, thereby severing any 
direct connection between this mode of oper- 
ation and the system processors. The result 
is an appreciable drop in effectiveness, and 
hence an overall diminution of system utility. 
Therefore a system which is to be seriously 
regarded as general purpose must find a way 
to integrate both modes easily into a common 
framework. 

Figure 3 illustrates how this can be done. 
Starting from the primary representation, 
processing follows one of two paths: either 
to direct execution, or to compilation in the 



"Of these, JOSS* and QUIKTRAN3 are perhaps 
best known. 



more traditional sense. The decision as to 
which path to follow might be left entirely 
to the user. More likely the total interest 
would be better served by having system con- 
trol make the choice subject to general rules 
laid down by installation management. A 
simple rule, for example, which would serve 
many installations well, would be to go to 
direct execution with (pieces of) programs 
which are yet undebugged. More sophisticated 
rules depend upon how much the installation 
is willing to acknowledge direct execution as 
an important option in any well designed on- 
line system. 

An interesting observation on this point is 
that since many currently announced compu- 
ters use read only memory for control and 
instruction interpretation, a little care in the 
design of the primary representation would 
make it possible to do most, perhaps all, of 
the interpretation in the hardware. This is 
tantamount to direct execution of a symbolic 
program (hence the choice of a name), a sub- 
ject of some interest today 6 ). The gain in 
efficiency would greatly enlarge the class of 
programs for which direct execution is a dis- 
tinct advantage. 

SECOND PHASE OF COMPILATION 

If the choice is to proceed to hardware exe- 
cution, the second phase of compilation is 
entered. The object of this phase is to convert 
the primary representation to program text 
which is the interface to system execution 
control, and hence to execution proper. Pro- 
duction of this text, the analogue of the relo- 
catable code used in most current systems, is 
carried out in the following manner, by a 
process which separates naturally into the 
functions of optimization, instruction genera- 
tion, and assembly (see Figure 3). 

Optimization. The first step is to apply an opti- 
mization procedure to the primary represen- 
tation, in order to improve the execution 
performance of the program. This involves 
such activities as flow analysis ; noting where 
auxiliary calculations may be better per- 
formed, and where they may be suppressed; 
analysis of loop structure to determine posi- 
tional indicator usage, common expression 
pre-calculation, and the possibility of loop col- 
lapse; all of which are done now in most 
compilers, though not, perhaps, at quite the 
same place. That this is the proper place for 
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such action is not hard to justify. It must 
occur following all modifications, since it is 
meaningless to optimize without knowledge of 
the entire context of the program; and it 
should precede any instruction generation, 
since preventive measures are always better 
than remedial ones. 

There is a further advantage in that it per- 
mits the easy mechanization of considerable 
latitude in the amount and type of optimiza- 
tion applied to any given program. A user, 
for example, might choose to skip all, or part, 
of the procedure if he has good reason to 
believe it will not notably improve his pro- 
gram. In this connection, the box marked 
"(weak) optimization" in Figure 3 merely 
signifies that some type of gross optimization, 
for example the loop collapsing analysis, 
might well be useful prior to direct execution. 

It should also be noticed that this step com- 
pletes the catalogue of information desirable 
in the primary representation, and so serves 
in implementation for the final determination 
of the functions undertaken by the conver- 
sion processors. 



Instruction Generation. The function of instruc- 
tion generators is to interpret statements 
within the (optimized) context of the pro- 
gram, and the hardware to be used for execu- 
tion, to decide which instructions are to be 
used. At this stage, the verbs of most proce- 
dural languages can be handled by autono- 
mous processors. Within these processors most 
remaining decisions can be made by selecting 
one of several pre-planned possibilities, ac- 
cording to the descriptions of operands within 
the scope of individual operators. For exam- 
ple, if the expression A+B is to be calculated, 
the addition generator would examine the 
data descriptions of A and B: if they were 
floating point numbers, a simple floating addi- 
tion sequence would be used; if fixed point, 
some preliminary scaling might be required, 
as well as the use of fixed point hardware 
operations. Thus the organization favors a 
high degree of modularity in the compiler ; it 
also localizes treatment of most changes in the 
interpretation of a statement to an easily 
accessible place. 

It must be clearly understood that the gen- 
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erators, in spite of their name, are confined 
to making decisions about what instructions 
to use, but do not themselves act to issue the 
instructions. This takes on added significance 
in view of the fact that these decisions are 
the same as those made in the implementation 
of direct execution, for it means that the same 
routines can serve this function in both paths 
of the compilation process. 

First Assembly is the name given to a small set 
of routines which operate concurrently with 
instruction generation to implement the deci- 
sions made by the generators. Hence, the main 
functions undertaken by these routines are to 
substitute particular instances of operands 
into lists of instruction forms, to (logically) 
separate and count the independent streams 
of instructions, and to record usages of sym- 
bols which will result in interprogram refer- 
ences. In this effort considerable use is made 
of advanced assembly techniques such as mul- 
tiple location counters and deferred symbol 
definition. First assembly, however, should 
not be confused with the first pass of a typical 
assembler, most of whose work is expended in 
conversion. 

In the direct mode this function is replaced 
by execution. More precisely, first assembly is 
supplanted by a routine which carries out, or 
attempts to carry out, the intent of the in- 
structions produced after the operand substi- 
tutions are made. 

Final Assembly embraces preparation of the 
form required by execution control ; and, per- 
haps, production of supplementary informa- 
tion for the user (such as a listing). Little can 
be said about the implementation of either of 
these functions since the processing is very 
much dependent on the form adopted for the 
program text, and the sophistication of the 
techniques used to take advantage of the 
available hardware. It should be noted, though, 
that the supplementary information, so com- 
mon in off-line systems, is of no practical 
utility to an on-line user and might well be 
eliminated. 

RELATION TO ON-LINE SYSTEMS 
The organization thus described embraces 
all the functions assigned to the compilation 
process, so that the picture of compiler struc- 
ture is essentially complete. Furthermore, the 
discussion has emphasized that the consider- 
ations used in developing this picture apply 



to most systems, being based on overall opti- 
mization of the user/ system relation. But in 
actual practice the compiler must operate, and 
produce code which operates, consistently well 
within the internal conventions and tech- 
niques of a particular environment. There- 
fore, to verify that the description is sound, 
that the structure is not just suitable but 
desirable, it is necessary to consider require- 
ments which are peculiar to dynamic environ- 
ments, particularly on-line systems. 

The salient feature of such systems is that 
they attempt to amplify the effective com- 
puting power of the hardware by the use of 
techniques which permit multiple concurrent 
users. Multiprogramming and multiprocess- 
ing, for example, exploit the possibilities of 
parallelism, while time sharing exploits the 
disparity in human and computer speeds. 
Much of the advantage gained by these tech- 
niques would be dissipated without effective 
resource allocation and minimization of sys- 
tem overhead. Segmentation of programs into 
fairly small pieces is by far the most signifi- 
cant factor in this effort, on both counts. 
First, it improves core utilization by reducing 
the occurrence of unused blocks. Second, it 
reduces system overhead because the presence 
of pieces of many programs in core at the 
same time has a double effect in diminishing 
the number of words swapped between core 
and backup storage. 

Now, it has already been observed that the 
organization presented is favorable to frag- 
mentation of the compiler itself. Moreover, 
the functional division simplifies use of tech- 
niques for dynamic reduction of the operating 
size. For example, the independence of indi- 
vidual instruction generators permits imple- 
mentation in which only those generators 
actually in use by any program need be 
brought into core, where they can remain un- 
til not needed. Further improvement can be 
obtained by designing the primary represen- 
tation to separate the global information from 
the local, which reduces the amount of data 
that has to be swapped in compilation ; and by 
limiting the size of any segment which is com- 
piled down to program text, thus limiting the 
space needed for such data. 

Limitation of the size of segments is a tech- 
nique practiced in many current systems. Its 
success depends upon having an execution 
control which can readily build, and efficiently 
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operate, a program composed of smaller seg- 
ments. In attempting to do this for on-line 
systems, there is much to be learned from 
software solutions already in use. That sub- 
ject, however, would need a lengthy discourse 
to do it justice. In this discussion, it is pos- 
sible only to touch briefly upon a few topics 
of general interest. 

First of all, program segmentation has its 
darker side. It increases the core management 
problem because of the appearance of frag- 
ments: small pieces left over in allocation 
which must somehow be collected into useful 
sizes. Similarly, program protection is more 
difficult, for occasions arise when non-contig- 
uous segments of the same program must 
reside in core simultaneously. The difficulties 
of interprogram communication are also mag- 
nified : the smaller the pieces, the more likely 
references will be external to a given segment. 
The first two of these problems occur only in 
dynamic systems, while the last has been 
around for some time. In attacking it, current 
systems have developed program text and 
loading techniques which could be quite useful 
if properly converted to a dynamic environ- 
ment. 

In those systems, program text consists of 
instruction strings in which the addresses are 
supplemented by relocation bits whose normal 
function is to indicate whether the address 
is constant or relative. For interprogram ref- 
erences, however, the encoding refers to a 
dictionary in which enough symbolic infor- 
mation is retained to identify the desired ref- 
erence. It is the function of that portion of 
execution control called the loader to combine 
various segments into a single operating pro- 
gram, as desired by the user. In this process, 
the text is translated to specific core locations 
by interpretation of the relocation bits in con- 
junction with the combined dictionaries. In 
addition, for programs too large to fit into 
core, the user indicates how the program is 
to be prepared for retrieval of specified parts, 
(called overlays) by execution control. 

Now in on-line systems this pre-planned 
retrieval and pre-calculated translation is 
better done dynamically. Not only would this 
improve efficiency by fetching only those por- 
tions of a program actually needed during a 
particular execution, but also it would provide 
relief from the fragmentation problem by 
severing the ties to specific locations. But 



implementation of such dynamic control en- 
tirely by software involves considerable over- 
head during swaps, and in execution, so that 
some hardware assistance is required. Two 
approaches are currently in vogue. First, 
there are page schemes in which segmentation 
and retrieval are tied to core blocks of hard- 
ware determined size and location. Second, 
there are address translation schemes in 
which the illusion of a contiguous program is 
obtained by comparing all effective addresses 
generated during execution with a translation 
dictionary to obtain a true address. Again 
the page concept is in evidence, since the 
translation shifts the low order bits of the 
address. 

Neither of these methods really eliminates 
much pre-planned effort on the part of the 
user or the system. Therefore it is surprising 
that there have been no serious attempts to 
embed the loading function into the hard- 
ware; that is, to design the CPU to execute 
program text directly, relocation bits, diction- 
ary, and all. Such an approach, which requires 
no more hardware than others proposed, has 
several distinct advantages. 

1 . It is quite conservative of space. The relo- 
cation bits can be absorbed into the address 
without any practical limitation on seg- 
ment size. Furthermore, the dictionary is 
only as large as required by the given 
program. 

2. It is efficient in execution. Address com- 
parison occurs only for instructions which 
specifically request it. 

3. Segmentation is performed according to 
the natural division of the user. The elimi- 
nation of artificial fences in core relieves 
system processors, for one, of the problem 
of adjusting recalcitrant segments to pre- 
specified block sizes 2 . 

4. Apart from the dictionary, the programs 
are absolutely location independent. If read 
only code is used, very little additional soft- 
ware is needed to implement a scheme in 
which segments of operating programs are 
swapped in, but need never be swapped 
out. 

5. Flags in the dictionary can be used to pro- 
vide program protection on an individual 
basis, not tied to any particular core loca- 
tions, and for any number of independent 
programs. Similarly, dictionary flags can 



113 



be used to trigger a segment retrieval 

mechanism. 

For these reasons, design of a program text 
in conjunction with hardware merits serious 
consideration. In this design, it is, of course, 
desirable to make use of negative as well as 
positive information gained from previous 
software experience. For example, the pro- 
gram text of several current systems, contains 
a dictionary for debugging as well as a dic- 
tionary for interprogram reference. Because 
of the reduction in symbolic content, and be- 
cause the nature of undebugged programs is 
such that one cannot anticipate what infor- 
mation will be needed, or when it should be 
obtained, considerable skill is required of the 
user to keep this dictionary of manageable 
size and still have it fulfill its purpose. More- 
over, loading is complicated by having to 



undertake the additional functions of inter- 
pretation and insertion of debugging requests 
into the program prior to execution. It is oper- 
ationally superior in all respects to eliminate 
the debugging dictionary and rely upon inser- 
tion of requests into the primary represen- 
tation. 

Objection might be raised that this is not 
suitable for code produced by assemblers. 
Such, however, is not the case. With the 
previous discussion as background, it is not 
difficult to quickly arrive at the functional 
organization of a processor for an assembly 
language family. Figure 4, for example, shows 
the plan of a macro assembler which would 
take source language through conversion and 
first assembly to a primary representation, 
and from there through final assembly to pro- 
gram text identical in form to that produced 
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by any other .system language processor. The 
primary representation, which is naturally 
quite different from that of a problem ori- 
ented language family, again serves as the 
resident symbolic form of the program, and 
as the point for incremental modifications. A 
significant feature of. this structure is that 
instruction generation and first assembly oc- 
cur prior to output of the preliminary repre- 
sentation. Hence the processing time from it 
to program text is substantially less than that 
of other families. Thus, user convenience, uni- 
formity of procedure, and overall operating 
efficiency combine to form a powerful induce- 
ment for a return to completely symbolic 
debugging. 

SUMMARY 
But to pursue these ideas farther would 
necessitate a depth of detail far beyond the 
scope of this paper. So, in conclusion, it is 
perhaps in order to summarize the main 
points of this discussion. First, consideration 
of the basic relationship between user and 
system, of the existence of many languages 
and the need for incremental changes, leads 
to a compiler whose first phase is dedicated 
to the production of a primary, internal, 
representation intended for residence in the 
system. This step is independent of any inter- 
nal considerations. Second, because of rapid 
intercommunications, on-line systems are par- 
ticularly suitable for direct, interpretative, 
program execution. The primary representa- 
tion then provides a means of unifying two 



distinct modes, interpretation and conven- 
tional compilation, at the same operational 
level. Third, a functional organization for the 
second phase of compilation based on current 
practice fits nicely with the special require- 
ments of the internal dynamics of on-line sys- 
tems. Finally, past experience indicates how 
compiler output might be designed, in con- 
junction with hardware, to alleviate some of 
the problems of segmentation, core allocation, 
and program protection. 
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The Quiktran System 



INTRODUCTION 

Systems involving access to a central com- 
puter by geographically distant users have 
been employed experimentally since the very 
earliest application of computers themselves 1 . 
During the early 1950's, these systems were 
commonly oriented towards the substitution of 
data transmission for the physical transporta- 
tion of the user or his data between remote 
locations and a central computer site. This en- 
abled some people to gain computer access and 
provided others with increased convenience 
and improved job turn-around times. 

During the second half of the last decade, 
military command and control systems (e.g. 
SAGE) involving concurrent access to a large 
computer from numerous consoles, provided 
a first indication of the potential advantage 
of coupling man and machine in processing 
complex problems. 

These early military systems stimulated the 
commercial application of the man-machine 
concept in the airline, brokerage, and banking 
industries. These systems are often character- 
ized by special purpose equipment and tailored 
software which are oriented towards a specific 
commercial application with emphasis on the 
maintenance and retrieval of data files. 

At the present time such customized tele- 
processing systems are being generalized as 
general purpose equipment and comprehensive 
on-line operating systems which are oriented 
towards a wide spectrum of scientific applica- 
tions with emphasis on both the processing of 
programs and manipulation of data files. 



''IBM System Research and Development Department 



SYSTEM CONCEPTS 

There are several feasible system approaches 
to provide remote scientists and engineers 
with many of the computing services long 
available to users located close to a digital 
computer installation. 

Batch Processing 

One is to envision the remote terminals as 
merely another type of I/O device. The 
simplest form of this approach is to limit 
these terminals to operating system input/ 
output (e.g. SYSIN and SYSOUT) and ex- 
clude their assignment to user problem pro- 
grams. Programs, data, and associated control 
information are entered and stored awaiting 
computer availability. This can be scheduled 
in several ways : the simplest is to await com- 
pletion of the current job, and then inter- 
sperse the stacked remote job into the input 
stream. Following conventional processing, re- 
sults are stored awaiting later transmission 
to the remote output unit. If no other remote 
jobs are ready for processing, the operating 
system selects the next job from its regular 
input source. Concurrently, results are trans- 
mitted (under control of either the main 
processor itself or else an -associated I/O 
processor) back to the remote sites. 

This remote batch approach has several ad- 
vantages 

1 . It requires a minimum of extra equipment 
and little additional software development. 

2. It is a logical extension of conventional 
batch processing procedures. 

3. Processing efficiency is high. 

4. Turnaround time is improved. 
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5. It is particularly suitable for "express jobs" 
(e.g. those involving small I/O volumes, no 
operator set up, and limited execution 
times.). 

But it has the following limitations : 

1 . Output print volume often (especially dur- 
ing program testing) overwhelms the ca- 
pacity of the communications terminal 
equipment. 

2. Although turnaround is improved, there is 
no opportunity for direct, sustained man- 
machine communication. 

Shared Processing 

A second, and currently more popular, ap- 
proach is to envision the remote terminals as 
computer consoles. This implies that the re- 
mote user should have immediate and sus- 
tained control over the central computer. 
Since it is economically unfeasible to have one 
user dominate the computer, its facilities 
(time and storage) are dynamically shared 
among a number of users. This form of multi- 
programming is often called time sharing, 
although another term such as "facility shar- 
ing" or "resource sharing" would be more 
appropriate since much more than the sharing 
of computer time is involved. 

SYSTEM REQUIREMENTS 
In the design of any computer system the 
following major considerations must be an- 
alyzed and evaluated: Who is the user, what 
functions are needed, at what cost, and for 
what purpose? More specifically, what size 
computer, how many users, what functional 
capability, and at what cost per user? 

The first factor can be recast into a ques- 
tion of extending an established market by 
enabling conventional computer applications 
to be performed in a new or improved manner 
and creating a new market by providing new 
capabilities not previously available. 

Capability must be structured in terms of 
price and function. In 1960-1961, when the 
first generation of time sharing systems were 
being designed, analysis of existing computers 
indicated the following: 

1. A comprehensive service could be made 
available to 20-30 terminals time sharing a 
large-scale computer. Quantitatively this led 
to the approximation of $4,000 per user per 
month; ($100K system)/ (25 users). 

2. A limited service could be made available 



to 30-50 terminals time sharing a medium 
scale computer. Quantitatively this led to 
the approximation of $1,000 per user per 
month ; ($40K system) / (40 users) . 
$4,000/month computers were widely avail- 
able and undergoing rapid improvement; 
$l,000/month computers were not commonly 
available. Two markets were considered: in- 
stall computers on large customer premises 
for shared usage by his employees, and service 
small users by leasing time from central IBM 
Data Center installations. The basic system 
goal was to realize new marketing and techni- 
cal innovations ; consequently, it was the med- 
ium scale system with limited capability ap- 
proach that was selected. 

The next consideration was to determine 
what functions should be provided. This can 
be subdivided into two areas: qualitatively, 
what does the market need; and quantita- 
tively, what performance is possible. 

The qualitative factor can be recast into an 
evaluation of the relative merits of a commer- 
cial or of a scientific orientation. The follow- 
ing factors were analyzed : 

1 . Amount of program development vs. pro- 
duction work 

2. Importance of job turnaround vs. com- 
puter throughput 

3. Amount of I/O vs. computing 

4. Amount of retrieval vs. computing 

5. Programming languages in use 

6. Conversion and transition problems 

7. Amount of application support required 

8. Random storage requirements (space, 
speed, and price) 

9. Density of potential users 

10. Reliability requirements 

1 1 . System load-up rate 

12. Sales expense 

13. Customer training requirements. 

It was concluded that, although the com- 
mercial market was undoubtedly much larger, 
there was substantially greater immediate 
revenue potential and lower technological ex- 
posure associated with a scientific oriented sys- 
tem. 

The quantitative factor can be recast into 
how computer performance is considered. 
First, the computer engineer is concerned 
with throughput, that is, the raw processing 
power of the system (often expressed in micro- 
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second units). Next, the computer center man- 
ager is concerned with turnaround time ; that 
is, the interval between submission of a job 
and the return of output (often expressed in 
hourly units). Finally, the computer user is 
concerned with solution time ; that is, the time 
interval between the decision to utilize a com- 
puter and the receipt of correct results (often 
expressed in weekly or monthly units). 

It was decided to place primary emphasis on 
the last factor since it is of paramount impor- 
tance to the new user and is a main source of 
dissatisfaction with many current users. 

SYSTEM DESIGN 

Objectives 

These system requirements were then trans- 
lated into the following design objectives. First 
the price, a $40,000 per month central com- 
puter configuration would be shared by 40 re- 
mote terminals. Next, performance; speed 
would be extrapolated downward from exist- 
ing small scientific computers. Relative to this 
class of computer: response rate would be 
under 10 seconds; execution speed would be 
in the range of 0.1-1; and compilation speed 
would be in the range of 10-100. Space would 
be equivalent to that available in small com- 
puters; that is 3,000-4,000 words. Finally, 
language; a source language would be con- 
sistently used for program statement, prob- 
lem debugging, and terminal operation. 



Approach 

It was immediately realized that the com- 
puter price objective would be exceeded if 
special device design or equipment modifica- 
tions were undertaken. Hence, a design con- 
straint to use only standard computer prod- 
ucts was imposed. 

It was also soon apparent that the perform- 
ance objective could not be realized merely 
by tailoring existing compilers for operation 
in a time shared environment because they : 

1 . Were too large for either in-core residence 
or for segmented swapping 

2. Strongly emphasized object performance 
at the expense of compiling speed 

3. Were not well designed for efficient re- 
compilation 

4. Were not effective for source language de- 
bugging 

5. Generated far too much output data for 
terminal operation. 

It was concluded that a new program de- 
sign was necessary. Two influences were para- 
mount in deciding on the approach. First, pre- 
vious experience in using the 701 Speedcode 2 , 
705 Prints, 705 Sale*, and G-15 Intercoms sys- 
tems had demonstrated the power of interpre- 
tive execution in the formulation and debug- 
ging of small to medium scale scientific pro- 
grams. 

Second, previous exposure to list processing 
concepts in IPL-V 6 had indicated that list 
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techniques should be particularly applicable to 
the design of incremental language transla- 
tors. 

It was relatively simple to settle on the best 
approach to meet the language objective. Be- 
cause of the importance of language compati- 
bility, extent of usage, and ease of learning, 
it was decided to base the language on a sub- 
set of FORTRAN equivalent to that available 
on small computers. 

EXTERNAL SPECIFICATIONS 

Since detailed information on QUIKTRAN's 
external design is available 7 , only a brief 
outline is presented. 

Equipment Configuration (Figure 1) 

1050 terminal for user console 

7740 exchange for communications control 

7040 computer for all processing 

7320 drum for program swapping 

1301 disk for user program libraries 

Language Specifications 

1 . Program statements, a FORTRAN subset, 
are used to write programs. 

2. Console statements are used to load pro- 
grams, to start and stop execution, and to 
enter and display data. 

3. Alteration statements are used to insert, 
change, and delete program statements. 

4. Display statements are used to display 
source program listings and storage dumps, 
pre-execution cross reference listings, in- 
execution data and flow tracing; and post- 
execution history of data usage and control 
flow. 

Operating Modes 

1 . Batch : for the remote entry of a complete 
job for conventional execution. 

2. Command: for use of the remote terminal 
as a symbolic desk calculator. 

3. Program: for the conversational entry and 
execution of FORTRAN programs. 

Operation 

Use of the system can be best illustrated by 
seeing it in actual operation.* 

The terminals shown in Figure 2 are con- 
nected on a typical operation. 

Equipment components are shown in Figure 1 . 





QUICKTRAN* 




Line No. 


User 


Location 


Distance 


1 
2 
3. 

4 


University 
Aerospace 


San Francisco, Calif. 
Los Angeles, Calif. 


3,000' 


5 
6 


Chemical 


Charlestown, W.V. 


500 


7 


Petroleum 


New York, N. Y. 


1 


8 


Education 


ii ii ii 


1 


g 

10 


IBM Engineering 


Poughkeepsie, N. Y. 
Endicott, N.Y. 


75 
150 


11 

12 


IBM Systems Res. 


San Francisco, Calif. 
Boston, Mass. 


3,000 
150 


13 
14 


.. M 


New York City 


1 
1 


15 


Demonstration 
(Mo/ie) 







♦Users on 


system when filming movie (9/24/64). 





FIGURE 2 

TERMINAL LOCATIONS 







C0MMAN0 


101. 


-READY 


N-l+1 


101. 


- 


N = 2 


101. 


-READY 


Z-1.+10.+100. 


101. 


- 


7.- 0.11099999E 03 


101. 


-READY 


EDIKF15.8) 


101. 


-READY 


Z»1.-2.«3.M.**5. 


101. 


= 


7.= 0.9941U063 


101. 


-READY 


Z»1.-2.*(3.M. )**5 


101. 


» 


Z = 0.52539063 


101. 


-READY 


Z-l. 23U5678*8. 765U321 


101. 


- 


Z« 10.82151997 


101. 


-READY 


Z-1.23UE01*i».321E-02 


101. 


« 


Z= 0.53321139 


101. 


-READY 


Z«SQRT(102U,) 


101. 


= 


Z» 32.00000000 


101. 


-READY 


Z-L0GF(SIN(1.23)**2*C0SF(1.23U)**2) 


101. 


■ 


Z- -0.00251082 


101. 


-READY 





*A 20-minute motion picture was shown at the Sym- 
posium. 



FIGURE 3 

SYMBOLIC CALCULATOR 

When the terminal is in use as a symbolic 
desk calculator (Figure 3) each user action 
elicits a computer response and vice versa. 
Each entry is used to introduce a new concept : 
integer values, floating point values, output 
formatting, arithmetic operation: +, — , *, /, 
**, use of parenthesis, high precision, scaling, 
function evaluation, and expression evaluation. 
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FIGURE 4 

CONSOLE OPERATIONS 

In the program mode (Figure 4) (e.g., entry 
of a program) some of the console commands 
are start, stop, entry, and display. The user in- 
dicates his intention to enter a program (by 
typing PROGRAM) and gives it a name (e.g. 
ROOT) so that he can later retrieve it from his 
library. The program consists of only two 
statements: the first to evaluate Newton's (or 
Heron's) formula for the square root; the 
next to set up an infinite loop. The user in- 
dicates the number whose root he desires 
(X=25) and initializes the iteration variable 
(Z). Then he begins execution (via START 0), 
lets it run a few seconds, and then stops execu- 
tion (via HALT). The system indicates the 
location of the last statement executed (anal- 
ogous to a console's instruction counter lights). 
The user then displays the current value of 
the square root and it is seen to be very close 
to the exact answer. 

Entering a program to solve the differential 
equation dy/dx=X*Y, X = O, Y = l, is an 
example (Figure 5) which illustrates many of 
the common clerical and syntactical errors 
usually committed in writing a FORTRAN 
program. The system immediately responds 
with a diagnostic message and the user can 
then easily correct the error. Such mistakes 
although trivial, often use up several machine 
runs, each involving several hours delay in 
advancing towards a checked out program. 
Notice also that the user may execute sections 
of the program as they are entered and verify 
results as he proceeds. 
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FIGURE 5 

PROGRAM ENTRY 

Figure 6 illustrates program testing. The user 
has pursued his completed program. He initi- 
ates execution (via START 0) and an alpha- 
betical heading and a line of numerical values 
print correctly. Then the system indicates that 
at line 114 an attempt has been made to use 
a variable before it has received a value. The 
user detects his error, deletes line 114 and re- 
places it with the corrected formula. He then 
indicates the end of alteration (so that the 
system can run a check to insure that he 
did not introduce new errors while making the 
change) and starts execution again. 
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FIGURE 6 

PROGRAM TESTING- 1 

Another error shows up at line 118 where 
an attempt is made to transfer to a non- 
existent statement (note : in later versions of 
the system this error is detected before execu- 
tion). The user corrects this error by number- 
ing the statement at line 111 with a label of 3. 
He starts execution again. Everything looks 
fine except that nothing is happening! The 
user performs a HALT, quickly begins to 
make a correction (Figure 7), cancels it, and 
then inserts, after line 113, a statement to 
increment the independent variable X. Once 
again, he, starts execution and (finally) the 
program runs to completion (PI at line 120). 

Being curious about the effect of step size 
on precision, the user then changes the step 
(DELX=0.25), and executes again (being 
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FIGURE 7 

PROGRAM TESTING-2 

careful not to execute the program statement 
that initializes DELX). The program runs 
to completion and he notes that an increase 
in step size (DELX =0.25 instead of 0.20) 
caused a difference (Y= 1.77429 instead of 
1.75111) in the value of Y. This illustrates 
some of the potential of close man-machine 
interaction in the area of numerical analysis. 
The next example (Figure 8) illustrates use 
of some of the source language debugging 
features. First, there is a DUMP of memory 
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- 




X- 0.12I»99999E 01 








- 




Y» 0.23287582E 01 






13U. 


♦READY 




EDITCF15.8) 








135. 


♦READY 




DUMP 












- 




DELX- 


0. 


25000000 








■ 




DELY- 


0. 


55>» i»6625 








- 




X» 


1.25000000 








■ 




Y- 


2.32875821* 






136. 


♦READY 
INDEX 
INDEX 
INDEX 




INDEX 
1 
2 
3 


♦103. 
+ 110. 
♦111. 


-122. 
-108. 
-118. 










INDEX 




it 


♦ 112. 


-111. 




\ 




INDEX 




5 


♦ 120. 


-118. 




1 




INDEX 


DELX 




♦ 102. 


-113.1 -111*. 




1 




INDEX 


OELY 




♦111*. 


-115. 




1 




INDEX 


•DIFEQ1 








1 




INDEX 


X 




+ 103. 


-111. +113.1 


-lli». 


-118. 1 




INDEX 


Y 




♦ 10U. 


-111. -11U. 


+ 115. 




137. 


♦READY 




INDEX(X) 






/ 




INDEX 


X 




♦ 103. 


-111. +113.1 


-111*. 


-118. 




138. 


♦READY 




CHECK 














CHECK 


•0IFEQ1 












139. 


♦READY 




AUDIT 














AUDIT 




122. 


/123. 


NOT XEO 








AUDIT 




0IFEQ1 


NOT 


SET 









FIGURE 8 

DISPLAY STATEMENTS 



under control of two different output formats. 
Next there is an INDEX cross reference list- 
ing of control flow and data usage. Finally, 
there is a CHECK for potential errors, 
followed by an AUDIT, a post-execution his- 
tory of actual control flow and data usage. 

In the next example (Figure 9) the user per- 
forms a LIST of the program he just finished 
testing. A variation of this would enable him 
to punch a card deck ready for processing by 
any other FORTRAN compiler. 







LIST 




101. - 


CF 


PROGRAM 0IFEQ1 \ 


102. - 




OELX-0.2 


103. » 




1 X-0 / 


10U. « 




Y»l 1 


105. « 










108. * 




PRINT 2 1 


110. » 




2 F0RMAT(5X,1HX,5X,1HY) \ 


111. « 




3 PRINT «»,X,Y 1 


112. « 




U FORMAT(F7.2,F8.5) 




113.1- 




X=X+DELX 




11«». - 




DELY=X*Y*DELX 




115. - 




Y«Y+0ELY 




118. « 




IF(X-1.)3,3,5 




120. » 




5 PAUSE 1 




122. * 




GO TO 1 




123. - 




END 1 


HI. +READY 









FIGURE 9 

PROGRAM LISTING 

INTERNAL DESIGN 
Introduction 

Since detailed information on QUIKTRAN's 
internal design is available 8 , only a brief 
outline is given here. The system is structured 
into two major sections (Figure 10). The proc- 
ess subsystem translates source statements to 
an equivalent intermediate representation that 
is then interpretively executed. The I/O sub- 
system controls the communications network 
and the swapping of programs between pri- 
mary (e.g. core) and secondary (e.g. drum 
and disk) storage. 

Records (Figure 11) 

The processor translates all source state- 
ments into two types of internal records. The 
fixed length element records, corresponding 
to source data and procedural elements, con- 
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INTERNAL ORGANIZATION 



tain the usual information collected in the 
early phases of all compilers (e.g., symbolic 
name, value attributes, and addresses). In 
addition, these records contain the value it- 
self and list control information. The variable 
length statement records, in one-to-one corre- 
spondence with source statements, contain the 
source data in a form that is more compact 
(to save space) and more suitable for execu- 
tion (to save time). 

Lists 

All records are organized by lists. Element 
records are chained on to one of 26 lists each 
containing all elements with the same initial 
letter. This not only reduces symbol search 
time but also facilitates the generation of 
alphabetized memory dumps and cross refer- 
ence listings. All statement records are chained 
onto two lists : one organizing the statements 
in entry order; the other classifying state- 
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ments by type. The former is used to deter- 
mine proper ordering when reconstructing the 
source program and when executing the inter- 
mediate text; the latter facilitates interstate- 
ment error checking. 

Addressing 

Essentially three distinct types of address- 
ing are employed; associative list searching 
for symbol matching, look at addressing for 
mapping internal identifiers to relative loca- 
tions, and implicit addressing (e.g., push- 
downs) for storage of intermediate arithmetic 
values and for control of DO nesting. 

Blocks (Figure 12) 

Each user program block consists of two 
parts; the header contains the control, re- 
location, and addressing data; the body con- 
tains the intermixed element and statement 
records. Each time a program block is 
swapped into primary storage, parts of the 
header are processed to reflect storage re- 
location and to accumulate usage statistics. 

Checking 

Checking is performed at four levels. First, 
composition checking for correct syntax with- 
in a statement (e.g. parenthesis imbalance). 
Second, consistency checking for proper as- 
sociation between statements (e.g., GO TO A 
FORMAT). Third, completeness checking for 



proper DO nesting, label referencing, and 
control flow. Fourth, limit checking for arith- 
metic spills, proper subscript values, and valid 
control branching. 

Control 

A 7740, a separate communications com- 
puter, controls the network of remote termi- 
nals performing such functions as terminal 
polling, code conversion, error checking, and 
buffering of messages awaiting computer at- 
tention. 

Scheduling (Figure 13) 

A section of the 7040 program continually 
samples a small in-core terminal status table 
to determine which user program will next 
receive service. 

Logging (Figure 14) 

Another 7040 control routine continually 
records usage statistics on magnetic tape for 
later off-line analysis and summarization. 

EXPERIENCE 

The system has been in experimental oper- 
ation since mid-1963. Early human factor 
analyses led to some revision in system func- 
tion and operating procedures 9 . Preliminary 
evaluation led to the decision in August 1964 
to announce the system as a standard IBM pro- 
gram product to be available for customer use 
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LOGGING 



in April, 1965. Further evaluation led to the 
December, 1964 announcement of Datacenter 
access to be available by mid-1965 from ter- 
minals installed on client premises. 

Initial operating experiences can be partly 
summarized by the following observations. 

The remote user must have the ability not 
only to state his program but also to control 
its execution. Thus, many functions conven- 
tionally performed by the console operator or 
by monitor control cards must be identified, 
structured, and defined by simple, yet com- 
prehensive, language commands. 

The remote user is, more often than not, an 
engineer or scientist, not a professional pro- 
grammer. Unnecessary sophistication (no 
matter how elegant) in the system language 
and operating procedures must be avoided. 
Remember too, the remote user does not 
usually have ready access to expert helpers 
and consultants. 

The remote user must be given the impres- 
sion that he is the only user. All possibility of 
interference by others must be prevented. The 
response rate should be reasonably uniform; 
uneven response fluctuations are particularly 
disturbing. In addition, some periodic terminal 
indication of action (e.g., console "blink") 
helps reassure the user that his program is 
running. Finally, there must be ways for the 
user and central operating personnel to com- 
municate both by transmitted messages and 
also by verbal exchanges. 

The terminal itself is a potent training tool. 
The ability to proceed at one's own pace, 



coupled with the immediate detection of most 
programming errors, enables most people to 
start using a terminal with very little formal 
training. 

Conversational, source language techniques 
benefit amateur users relatively more than 
professional programmers who already under- 
stand machine language and know how to 
debug effectively. Experienced programmers 
are strongly conditioned to traditional batch 
computing techniques and have considerable 
trouble in adapting to the conversational ap- 
proach. 

The types of problems run from remote 
stations differ from those entered at a con- 
ventional computer installation. There are 
many more relatively simple problems pre- 
viously processed on desk calculators, slide 
rules, or small computers. Problems with large 
input/output volumes are obviously not suit- 
able for remote operation. This is also true 
of many production type problems where ob- 
ject efficiency is important and there is little 
need for the injection of human insight, judg- 
ment, or experience. Conversely, the debugg- 
ing of complex programs is greatly facilitated 
not only in terms of elapsed time and expense, 
but also in terms of the user skill level. 

Time sharing systems are very complex, 
difficult to develop, and challenging to debug. 
The system must be designed with these 
factors in mind. In particular, it is essential 
to provide means of measuring such factors 
as user and system response rates, use of 
language features, causes of errors, and equip- 
ment utilization factors. This data can be used 
to simulate alternative system configurations 
and scheduling algorithms and thereby lead to 
improved system performance. Analysis of 
this data is also essential to designing im- 
provements in the language specifications, 
operating procedures, and training methods. 
Finally, the data provides a means of equitably 
allocating overall system expenses among the 
individual users. 

Man-machine systems are no magical pana- 
cea. Properly applied they can be very effec- 
tive ; improperly used, they prove to be a very 
expensive novelty. 

EXTENSIONS 
Although the QUIKTRAN system uses type- 
writer oriented consoles, other terminal equip- 
ment could be employed : dictation to a remote 
terminal operator, dialed input with audio 
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response 10 , or graphic input with visual dis- 
plays 11 . 

System performance could be greatly en- 
hanced by computer organizations that pro- 
vide improved interrupt capability, object time 
address protection and relocation, larger pri- 
mary storage, and secondary storage equip- 
ment with faster access times and data rates. 

System performance could also be improved 
by a program design that permits the inter- 
mixed generation of object code along with 
the interpretive intermediate representation. 
Execution efficiency of the intermediate code 
could be improved by incorporating some of 
the frequently used interpretive functions into 
micro-programmed logic contained in a read 
only storage 12 . 

It is also profitable to explore the transla- 
tion of several different source languages into 
the same intermediate form. This would not 
only reduce implementation time and expense 
but would also serve as a useful vehicle for 
translation between related source languages 13 . 

From a marketing viewpoint, small systems 
i*. is like QUIKTRAN will undoubtedly be 
absorbed as subsets of larger time sharing sys- 
tems 16 - 17 - is. However, it is also probable that 
the stand alone, shared system will continue to 
provide functional capabilities in the range 
between the desk calculator and the small 
computer. Initial use will include the areas 
of scientific computing, text editing, computer 
assisted instruction, and certain commercial 
applications. 

CONCLUSIONS 

The QUIKTRAN system demonstrates that 
a standard medium scale computer can be 
time shared to provide an economical, but not 
fully general, form of computer service. It is 
also indicative that effective remote comput- 
ing requires not only different real time oper- 
ating systems but also new approaches to 
translation (e.g., incremental) and debugging 
(e.g., source language) techniques. 

It appears that the system offers little, if 
any, economic improvement over conventional 
small computers if measured in established 
throughput 19, 20 units. However, there are sig- 
nificant advantages in terms of improved con- 
venience, faster turnaround, higher manpower 
productivity, lower personnel skill levels, and 
greatly reduced total solution time and expense. 



Most importantly, such systems not only per- 
mit old problems to be solved in new ways, but 
also enable new users to solve new problems in 
ways not hitherto possible. It is this factor that 
will lead to wide utilization of similar man- 
machine systems in a wide spectrum of ap- 
plications. 
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Glen D. Johnson* 



THE PAT LANGUAGE 



The system to be described is an on-line 
interpreter for a structured, algebraic lan- 
guage. This interpreter is operating on the 
UCLA Computing Facility 7094 with the 
SWAC computer used to maintain a type- 
writer console. There is also a similar inter- 
preter for the IBM 1620. The 1620 version 
was produced by Dr. H. Hellerman of the IBM 
Advanced Systems Development Division in 
Yorktown Heights, New York, where it has 
had several hundred hours of productive use. 

The language is called the Personalized 
Array Translator— just PAT for short. The 
PAT language is a subset of the IVERSON 
language which was designed by Dr. Kenneth 
Iverson of IBM as a mathematical description 
tool. The character set used by Iverson has 
been reduced to a manageable size in the PAT 
implementation. 

A program in the PAT language operates 
on data which is highly structured. The basic 
data structure is considered to be a vector. 
Each symbolic name is specified by the sys- 
tem's operator to be either a scalar, a vector, 
or a matrix. Data names specified to be mat- 
rices or vectors also must have their maxi- 
mum sizes specified. There are statements in 
the language to access and modify the sizes 
of variables. 

Each variable is stored by the system as a 
vector with matrices represented as a series 
of column vectors stored in the computer. 
Scalar data items are represented as vectors 
of unit length. 

Currently, the 7094 system allows Boolean 
and floating point data items. Floating point 
constants are represented as numbers with or 
without a decimal point. False is represented 



by 0, true by 1. A constant may appear any- 
where that a variable is allowed. 

PAT allows portions of data items to be 
operated on using a subscripting rule. All 
subscripting is zero-origin with X as the first 
element of X. A single element may be selected 
from a vector by using one subscript or from 
a matrix by using two subscripts. A vector, 
either row-wise or columnwise, may be 
selected from a matrix by giving one subscript 
with an indication that the other subscript is 
empty. 

For example, let S be scalar, V be a vector, 
and M be a matrix. Then : 
VS is a scalar 

M SI S2 is a scalar 
MS is a row vector 

M . S is a column vector 
A . indicates an empty position 

Most statements are of the form : 
Variable— Expression 
They have the conventional meaning: the 
value of the expression is computed and stored 
in the variable on the left. 

This meaning is extended by allowing vari- 
ables to have more than one element. An ex- 
pression is evaluated using the first element 
of every variable contained in it to form 
the first element of the resulting variable. The 
expression is then evaluated using the next 
element of each argument to form the next 
element of the result, and so on until the 
resulting variable is filled. 
For example, if 
X=l, 2, 3, 5 
and 

Y=7, 11, 13, 17 
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and the current size of Z is 4, after execution 
of 

Z=X+Y 
the value of Z is 

8, 13, 16, 22 

If the end of any variable in an expression 
is reached before the left part of the statement 
is filled, indexing on this variable is restarted 
at its first element. 

This may be formalized by considering each 
operand, having a length L to be periodic of 
period L. The interpreter stores the first cycle 
of each variable and generates later cycles 
as copies of the first cycle. 

There are three types of data combination 
operations allowed by the PAT system. They 
are binary operations, unary operations, and 
reduction operations. Binary operations are 
represented in infix form as an operator be- 
tween two variables and include addition, 
subtraction, multiplication, division, and maxi- 
mum, minimum, and, or, and relational opera- 
tors. 

BINARY STATEMENTS 
X=Y+Z 
X=Y-Z 
X=Y*Z 
X=Y@DIV Z 
X=Y@MIN Z 
X=Y@MAX Z 
X=Y@EXP Z 
Note: Operation names are preceded by "@", 
and only the first character of name is 
used. 
Unary operations include trigonometric and 
logarithmetic operations. 

UNARY STATEMENTS 

X=@SINE Y 

X=@COS Y 

X=@ABS Y 

X=@LN Y 
Reduction operations are binary operations 
across data structures. Summation is a spe- 
cific case of reduction. In general, any binary 
operation is applied to a vector or a matrix 
as: 

+ / Vector Summation 

/ V Generalized 

V o 0V 1 0V 2 ...V n 

/ Matrix Row Reduction 

/ / Matrix Column Reduction 



For example, to compute : 

n n 



£ 



X = 



X i 

o i 



n 



jLi (x— x) 



n 



we write: 



XB = + / X 
XB=XB @DIV N 
T =X-XB 
T =T * T 

S =+ / T 
S =S@DIV N 



sum X 
over N 
differences 
squared 
summed 
over N 



To read and print data for this, we write : 



@GET 
@ DIM 
@D 
@G 



N 

X,N 
T,N 
X 



@TYPE XB 

@T S 

A statement line may be labelled. If a line 
is given a name, the name starts in the first 
position of the line. Otherwise, the first posi- 
tion is blank. 

Normal sequencing of a program is from 
top to bottom, left to right. Sequencing may be 
changed and explicit looping effected with a 
compare statement. 
1=0 
L ZI . = X . I 
1 = 1 + 1 
I @CMPN, L, L, 
The console has a series of commands used 
to communicate with the program. These have 
a * in the first typed column of a line. They 
are: 



*R 

** 



Reset system 

Define symbols, followed by 



(name) Vector f |^ lo f mg [diml] [dim2] ) 
(Matrix! (Boolean j 

: E [name] Enter program statements 

(program statements) 
f X [name] Execute program 
: D name Display 
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An Example of 
Multi- Processor Organization 



INTRODUCTION 

As the purpose of this meeting is the free 
exchange of ideas, it is necessary to establish 
the means of communication by denning the 
terms in this title. We hope to continue on- 
line throughout this discourse. 

The justification for the inclusion of this 
subject in this symposium is the fact that at 
some point in time someone will put together 
a system to handle a multiplicity of problems 
on-line. Before programs can be run on such 
a system they must be organized in such a 
manner as to facilitate their execution. By 
exploring ways to organize programs now we 
will be better able to utilize the hardware 
when it becomes available. 

DEFINITIONS 

The kind of example we will show is that 
of a method. References to hardware will only 
be used to demonstrate feasibility and the 
fact that the ideas discussed are not novel. 
The intent of this paper is to show a method 
which presents some interesting possibilities 
for further exploration. 

Before defining multi-processor it is neces- 
sary to accept a definition of a processor. We 
consider a processor to be an assembly of 
hardware which is capable of performing one 
or more arithmetic or logical functions in a 
specified manner. By this definition the word 
processor could describe a device which only 
performs addition. It could also be applied 
to the computing unit of the LARC. This leads 
to a definition of a multi-processor as being 
any mixture of processors which share one 



or more components such as memories, input 
devices or output devices. This permits us to 
include the MARK ID and the Bell Labs MOD 
V 2 in the category of multi-processors as well 
as the LARC itself. Each of the above contains 
two processors by our definition. A more com- 
plex array is presented by the ENIAC as de- 
scribed in Patent Number 3,120,606, granted 
Feb. 4, 1964. The ENIAC contained twenty 
accumulators. In addition to operating on two 
problems concurrently, the ENIAC could per- 
form several operations at the same time 
on one problem. All of these systems are con- 
sidered, in this paper, to be multi-processors. 

Whenever two or more pieces of anything 
are put together they must be organized. 
Certain customs or environmental conditions 
often impose constraints on the organization. 
Even though the engine can be found in either 
the front or the back of an automobile, the 
driver's seat remains in the front. A horse 
is generally placed in front of the cart it is 
intended to pull. The element of direction or 
control is integral to any organization of 
pieces required to do work. This paper will 
describe how the control of a multi-processor 
can be set up to provide the response times 
needed in closed loop applications as well as 
the generalized treatment required in time 
sharing systems. We are not concerned with 
the capability of the individual processors but 
rather with the broad question of the organi- 
zation of work to be performed by a multi- 
plicity of processors. We do not consider that 
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the assignment of one procedure to one proc- 
essor while other processors remain idle rep- 
resents efficient utilization of the hardware. 

The idea of a system comprising a multi- 
plicity of processors seems to be a natural 
extension of the time sharing concept. Time 
sharing was the outgrowth of the imbalance 
between CPU and I/O device speeds. If the 
CPU was loafing, it was given more work to 
do. We now have the line capability to over- 
load one CPU within an installation. The 
logical extension is to provide more than one 
CPU. The question immediately arises— what 
does one do if there is only one problem to 
be run at this time? Is it satisfactory to use 
only one of the CPU's which are in the system? 

Various schemes have been proposed for the 
design of multi-processors of varying capa- 
bilities—the Holland system 3 and the Solo- 
mon computer 4 are examples of this. Con- 
cepts of control are being explored by many 
research groups. The application of NDRO 
memories is increasing. A similarity is noted 
between the use made of NDRO memories and 
the utilization of the function tables of the 
ENIAC 5 . The organization of the ENIAC 
permitted the programmer to organize the 
solution of a problem so that more than one 
arithmetic operation was being performed at 



one time. This was difficult, but was one way 
to shorten the execution time for a problem. 
We are faced, today, with the same logical 
problem as faced ENIAC programmers. The 
difference lies in the fact that we now have 
a variety of gear and a multiplicity of prob- 
lems brought together in a multi-dimensional 
array. It is our thesis that it is possible to 
automate the organization of a single pro- 
cedure to maximize the utilization of multiple 
processors. 

Unless the organization of the procedure 
is performed according to a very rigid set 
of rules it will provide another source of 
subtle errors. While it is assumed that all 
parts of a stated procedure are interrelated 
within the total network, it does not follow 
that all steps must be performed in series. 
One of the ways in which processors gain 
speed is to overlap input, processing and out- 
put. We now want to extend this philosophy 
to the internal parts and determine the extent 
to which overlaps can occur within the proc- 
ess. Some equipment provides "look ahead" 
which permits the overlapping of the time 
of instructions which occur in series. This is 
accomplished within a single processor. When 
dealing with a multiplicity of processors simi- 
lar functions could be performed in parallel. 




FIGURE 1 

PERT NETWORK 
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FIGURE 2 

PERT NETWORK ARRANGED BY TIME PERIOD 



This can be achieved at the software level by 
what we choose to call "plan ahead". The 
organization can be accomplished by the com- 
pilers and the executive routines. 

We must make several basic assumptions 
and accept certain definitions in order to de- 
velop a set of rules : 

1. A procedure is defined as the collection of 
operations required to produce specified 
output data from specified input data. 

2. A procedure generally consists of a set of 
subprocedures which are linked together 
in the form of a network. 

3. An individual subprocedure can be defined 
as a completely self contained process with 
a prescribed set of inputs and outputs. 

4. The communication between one subpro- 
cedure and any others occurs only at the 
beginning and at the end of the subpro- 
cedure. 

5. It is possible to depict the flow of data by 
means of a diagram which shows the inter- 
relationship of all subprocedures within the 
procedure. 

6. The flow diagram can indicate those sub- 
procedures which could be executed in par- 
allel. 

PROCEDURES 
Figure 1 and Figure 2 demonstrate an ap- 
plication of these definitions. Figure 1 is a 
PERT chart of a procedure 6 . Each of the 



33 numbers represents a subprocedure. Figure 
2 shows the same flow diagram arranged to 
indicate the parallelism possible. In Figure 2, 
the lines connecting the subprocedures have 
been identified with letters which we will use 
to denote the data (operands) flowing between 
the subprocedures. Twelve of the subpro- 
cedures fall into time periods by themselves 
(1, 2, 8, 19, 20, 21, 23, 26, 29, 30, 32, 33). 
Eighteen can be paired : 
6, 7 9, 12 10, 13 11, 14 
15,17 16,18 22,31 24,25 27,28 
One group could contain three (3, 4, 5). If 
we shifted either 3 or 4 to occur in the same 
time period as 8, a two processor system could 
accomplish the entire procedure in twenty-two 
time periods. The reduction in time over a 
serial operation would be the sum of the times 
for the shorter of each of the eleven pairs of 
subprocedures. One of the processors would be 
available for the execution of another pro- 
cedure during the eleven time periods when 
the illustrated procedure does not permit par- 
allel execution of its subprocedures. 

This example is used to indicate the method 
by which a reduction in elapsed time could be 
achieved. The evaluation of any saving re- 
quires additional specifications such as the 
time for each subprocedure. This is related to 
the problem and the hardware. The method is 
independent of the specifications of either the 
problem or the hardware. The first question to 
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be resolved is whether the problem lends itself 
to parallel operation. The second is to measure 
the savings which could be achieved. 

An improvement in running time can be 
achieved by proper pairing (in a two proces- 
sor system). Depending on how nearly the 
time requirements match, the pairing of 5 
with 4 and 3 with 8 might be better than pair- 
ing 5 with 3 and 4 with 8. Similarly, 31 should 
be paired with an operation which requires 
more time than it does. This could be 22, 23, 
26, 29, or 30. The rule is that a subprocedure 
which could be performed in one of several 
periods should be paired where possible with a 
subprocedure which required more time than 
it does . If not possible, the longest fixed posi- 
tion subprocedure should be used. 

A further consideration in selecting time 
periods in a complete procedure is the storage 



of intermediate results. To shorten the period 
for storing intermediate results it might be 
better to perform subprocedure 3 in parallel 
with subprocedure 8, even though 3 is shorter 
than 5 and longer than 8. Such considerations 
are of value only where there are alternatives. 
The fact that alternatives do exist is evident 
from a visual examination of Figure 2. 

If the procedure were large, of several thou- 
sand subprocedures, a visual representation of 
the entire net would be very difficult to pre- 
pare. It would also be difficult to examine and 
analyze. It is possible to represent the intelli- 
gence represented by Figure 2 in a form which 
can be used for processing by a computer. 
Table 1 contains this information. List I shows 
one entry for each operand result relationship 
arranged in order by subprocedure identifica- 
tion. List II is the same data arranged in order 
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by operand identifier. List III is the same data 
arranged in order by result identifier. As sub- 
procedure 1 and subprocedure 33 do not each 
have an input and an output, they are not in- 
cluded in the lists. By truncating List I at 
different points and rearranging the re- 
mainder into Lists II and III, a variety of 
combinations can be produced. 

Subprocedure 2 generates three table en- 
tries. Subprocedure 11 generates six entries, 
while subprocedure 16 generates only one 
entry. The rule is that each subprocedure 
generates a number of table entries equal to 
the product of the number of inputs times the 
number of outputs. Each entry must appear 
in each of the three tables. To facilitate sched- 
uling, each entry should carry additional data 
concerning the facilities used by the sub- 
procedure, the input and output volumes in- 
volved and the time required. If this is done 
the complete network can be timed out, sched- 
uled, and controlled for any combination of 
processors. 

Before describing the techniques to be ap- 
plied to the three lists and the results which 
can be secured* it is necessary to delimit the 
terms further. 

1 . An operand is all of the data which flows 
from one subprocedure, or an input, to an- 
other subprocedure, or an output, in one 
movement as one record or piece of intel- 
ligence. Thus it can be an element of data, 
as a quantity to be added, or a set of data as 
a stock record. It must be received from 
some point outside the subprocedure which 
operates on it. 

2. Parameters which are used by a subpro- 
cedure are not considered to be operands 
within this definition. This does not pre- 
clude their use in arithmetic or logical 
operations within a subprocedure. 

3. The definitions of individual subprocedures, 
operands and parameters are always unique 
within a given environment consisting of 
problems and hardware. 

The treatment of necessary prior conditions 
will be discussed later. We seldom go through 
all paths in all subprocedures for one record 
or piece of intelligence. Conditions which must 
be met before executing an individual path 
represent intelligence which is derived from 
the data processed. There are options in the 
way such conditions are treated, depending on 



the problem and the hardware. For this reason 
a discussion of their treatment is deferred. 

ORGANIZING PROCEDURES 
The technique outlined below (Steps 1 
through 6) produces a list which represents 
the same time series as shown in Figure 2. If 
the operation is started with the final results 
(Steps 1 through 6A), a list is produced which 
shows the last possible time period by which 
subprocedures must be executed. 
Step 1 —Compare the Operand Fields in List II 

with the Result Fields in List III. Note 

four conditions: 

a. O Field in List II does not match an 
R Field in List Ill- 
Record items on a list of Unmatched 
Operands— 

O R SP 

A B 2 

A C 2 

AD 2 

This condition must be noted for each 
relative time period when analyzing the 
subprocedures for first possible time 
period. It will be ignored when analyz- 
ing for the last possible time period. 

b. O Field in List II does match an R 
Field in List Ill- 
Record items on a list of Matched 
Operands. This is a reduced List II. 

c. R Field in List III does match an 
Field in List II- 

Record on a list of Matched Results. 
This is a reduced List III. 

d. R Field in List III does not match 
an O Field in List II- 

Record on a List of Unmatched Re- 
sults. 

R O SP 

AR AD 32 

AR AQ 32 

This condition will be ignored when 
analyzing for the first possible time 
period. It must be noted for each rela- 
tive time period when analyzing for 
the last possible time period. 

Series for first possible time period- 
Step 2— Rearrange the data from Step la to 
read- 
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Sort on the R Field. 
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Step 3— Delete the items from the List of 
Matched Results (Step lc) which are 
identical to those from Step 2. If this 
deletion removes all references to the 
result identifiers we state that these 
results can pe secured in the first rela- 
tive time period. 

Step 4— Rearrange the data from Step 2 to 

read— 

SP O R 

2 A A B 

2 A C 

2 A D 

Sort on the SP Field. 

Step 5-Delete the items from List I which are 
identical to those from Step 4. If this 
deletion removes all references to the 
subprocedure identifiers we state that 
these subprocedures can be accom- 
plished in the first relative time period. 

Step 6 and continuing— Repeat Steps 1 through 
5 for successive time periods until Lists 
I, II and III are exhausted. 

Series for last possible time period. 

Step 2 A— Rearrange the data from Step Id to 

read— 

O R SP 

AD AR 32 

AQ AR 32 

Sort on the Field. 
Step 3A-Delete the items from the List of 
Matched Operands (Step lb) which 
are identical to those from Step 2A. 
If this deletion removes all references 
to the Operand identifiers we state 
that these operands must be used by 
the last relative time period. 
Step 4A— Rearrange the data from Step 2A to 
read— 

SP O R 

32 AD AR 

32 AQ AR 

Sort on the SP Field. 
Step 5A— Delete the items from List I which 
are identical to those from Step 4A. 
If this deletion removes all references 
to the subprocedure identifiers we 
state that these subprocedures must 
be accomplished by the last relative 
time period. 
Step 6A and continuing— Repeat Steps 1, 2A 
through 5A for preceding time peri- 
ods until Lists I, II and III are ex- 
hausted. 



Unusual conditions can be detected by this 
technique. The operands which are initial in- 
puts, and the results which are final outputs, 
are identified as the lists secured in Step la 
and Id the first time. Any errors in their 
identification are corrected before performing 
the other steps. In addition, if items remain 
in Lists I, II and III and no items fall out in 
step la or Id as the case may be, a closed loop 
exists which must be corrected. 

Table 2 shows the results of this analysis by 
relative time period. The fact that subpro- 
cedures 3, 4 and 31 can each be scheduled in 
one of several relative time periods is evident. 
The selection of the best fit can be accom- 
plished on a computer by applying the rules 
stated previously. One of the advantages which 
can be gained by using a multiprocessor is the 
reduction in the time and effort required to 
store and retrieve intermediate results. 

The above technique organizes the sub- 
procedures which produce results. For each 
relative time period, that subprocedure which 
requires the greatest amount of time can be 
identified. The complete chains of subpro- 
cedures which can be assigned in series to one 
processor can be identified. The exchange of 
data between processors can be scheduled to 
minimize memory requirements. These are 
positive benefits which can be achieved with 
this technique. It applies a modification of 
PERT and CPM to the organization of work 
for a computer. 

CONDITIONS 

The treatment of necessary prior conditions 
can be accomplished with the same technique. 
We need only to regard a comparison, which 
determines the path to be followed between 
subprocedures, as generating data. For our 
purpose we treat intelligence about data in the 
same way we treat the data itself. It is only 
necessary to identify this intelligence in the 
same way we identify data and then proceed 
through the same steps. We can identify in- 
telligence about data with the form : 

Operand 1, Operand 2, Value. 

Operand 1 and Operand 2 can be data fields 
or can be literals. Any data fields must be 
shown as an input to the subprocedure per- 
forming the comparison. The value field is 
considered necessary because we can never 
have only one such result coming from a sub- 
procedure. The value field permits a verifica- 
tion that all conditions have been considered. 



136 







■ 


rABLE 2 
















ALLOCATION 


OF SUBPROCEDURES 










Relative Time 


First 


possible 


execution 


Las 


t poss 


ible execution 


Period 


of 


Sub- Procedure 




of 


Sub- 


-Procedure 


1 




2 












2 


2 




3,4>5 












5 


3 




6,7 












6,7 


4 




8 












8 


5 




9,12 












9,12 


6 




10,13 








3, 


4 


,10,13 


7 




11,14 












11,14 


8 




15,17 












15,17 


9 




16,18 












16,18 


10 




19 












19 


11 




20 












20 


12 




21 












21 


13 




22,31 












22 


14 




23 












23 


15 




24,25 












24,25 


16 




26 












26 


17 




27,28 












27,28 


18 




29 












29 


19 




30 












30,31 


20 




32 












32 



The sum of all value fields must equal seven 
for each comparison. 



TABLE 3 


CONDITION VALUES 


ON COMPARISONS 


Condition 
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From the foregoing it is obvious that the 
simplest technique to use for comparisons 
which affect branching between subproce- 
dures, is to treat the comparisons as sub- 
procedures by themselves. Each decision af- 
fecting branching would be a subprocedure. 
This leads us to an alternative method. The 
main flows of data in a multi-processor could 
be executed without regard to data dependent 
branching. All data dependent decisions could 
be made by a separate processor and the 
proper final results selected. By this method 
some operations would be performed which 
would prove useless. Depending on the envi- 
ronment this alternative might save consider- 
able elaped time. 
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COMPILING AND EXECUTING 
We assume that the organization of the 
procedure will take place prior to the com- 
pilation of an object program. The compiler 
should be able to provide, with the loadable 
program, all of the intelligence concerning the 
network, the time periods and the execution 
times for each subprocedure. In turn the ex- 
ecutive or monitor routine must be able to 
treat each scheduled subprocedure in the same 
manner as it treats any interrupt from an out- 
side source. A subprocedure would take on the 
priority of its governing procedure. In effect 
we are subdividing every piece of work to be 
done into the smallest practical unit. A sub- 
procedure could be the inversion of a matrix 
or the comparison of two data fields. The 
compiler determines how the work can be sub- 
divided and over-lapped. The executive routine 
determines which component shall execute it 
and when. 

HARDWARE 
To provide complete flexibility in the hard- 
ware associated with the central memory, a 
binary addressing scheme seems to be the 
logical choice. It also seems desirable to pro- 
vide one static register per processor with a 
bit size equal to the memory width. Each pro- 
gram would be assigned a base register which 
would contain a binary number, the starting 
bit address. Each processor can contain a one, 
two, or three bit multiplier (hardware) which 



would operate on the address portion or por- 
tions of an instruction before incrementing 
with the base register. If a processor contains 
only two static registers and a plugboard, all 
intelligence as to sequence must be within an- 
other processor, possibly the one which con- 
tains the executive routine. 

CONCLUSION 

We have described a technique to break 
down the solutions of problems to permit 
maximum parallel operation within one prob- 
lem. We have not described in detail the hard- 
ware needed to execute programs in this 
manner. We consider that the hardware will 
be developed. 
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On-Line Computing Systems: 
A Summary 



On-line computing was defined by Walter 
Bauer as the efficient use of a computer in a 
system in which the computer interfaces with 
man or other machines, to which it reacts in 
receiving and supplying information. Review- 
ing the six kinds of on-line systems described 
by Ivan Sutherland, I would propose the 
following revision of the definition : 

"On-line computing is the use of a 
computer interfaced with man or 
machines, to which it reacts in re- 
ceiving, processing, and transmit- 
ting information." 

I am most interested in the interface with 
man, and here the computer is on-line if the 
man awaits the computer's response, not hav- 
ing turned his attention to other matters. 

It is clear that during the era 1949 until, 
perhaps, 1954, all automatic computers were 
essentially used in an on-line manner. In other 
words the customer sat at the console, pushed 
buttons, and tried to interpret the displays 
(binary neon indicators) in terms of the ex- 
pected progress of the problem. 

In 1954 with the delivery of large com- 
mercial computers (with more attention to 
actual dollar costs) it was no longer sensible 
to let a user flounder through a problem by 
pushing buttons and "thinking" at a console. 
Thus, we have the era of BATCH PROCESS- 
ING. 

Now in 1965, using the experience gained in 
developing military systems, many efforts are 
underway to improve the communication be- 
tween man and the computer. Obviously the 
man will make maximum progress on his 



problem if he can work on it with sustained 
attention. This implies the use of a personal 
console available to the man for relatively long 
periods of time. In most situations his opti- 
mum progress on his problem requires com- 
puting over very short intervals of time. Con- 
sequently, a well organized central computer 
capable of servicing many low cost stations 
is required. 

ECONOMICS OF ON-LINE COMPUTING 

At the University of California in Berkeley 
16,000 problem passes were made in the month 
of January, 1965, on the DCS (7040-7094) 
system utilizing 57 percent of the available 
computer time. The average problem time was 
1.56 minutes and the average equipment cost 
per problem-pass was $3.00. The cost of ex- 
pendable supplies per problem-pass was about 
$0.30. 

The capital cost of a teletype style station 
ranges from $400 to $2,000, and communica- 
tion costs range from $2.00 per month (for 
direct lines on the Berkeley campus) up to 
$4,300 per month for a leased private voice- 
grade line across the United States. 

Since the teletype user can see the imme- 
diate effect of his editing of his program he 
will use substantially more central computer 
time. I estimate three times as much which 
I think is a conservative figure. 

Certainly the use of the on-line stations 
reduces the use of cards and high speed printer 
supplies. Let us assume that this goes to zero 
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and that the cost of paper and ribbons for 
teletypes can be ignored. If a teletype station 
is used 300 hours per month (14 hours per 
day for a five day week) and costs $150 per 
month (the price of a QUIKTRAN station - 
note that Morrissey quotes $1,000 per month 
per station as total cost), then the remote- 
station hardware cost per problem is $0.50 
on the basis of one hour use. Central computer 
use per problem is probably up by a factor 
of three, e.g. instead of three compilations to 
debug a ten statement problem there is per- 
haps eight to ten passes. 

Therefore, the actual cost of doing a prob- 
lem using remote stations on the basis de- 
scribed above is perhaps three times the cost 
by batch processing methods, primarily be- 
cause of the extra problem-passes which can 
be easily taken from the console. 

Certainly reduction in cost of in-output 
equipment at the central computer, improved 
methods such as incremental compiling (state- 
ment by statement), incentives to encourage 
non-wasteful use, can improve the cost ratio. 
However, even under optimum arrangements 
the total problem cost for remote station com- 
puting appears to be perhaps twice that for 
batch processing. 

Those who argue that remote station com- 
puting will be cheaper, do so on the basis that 
(1) incremental compiling will permit clearing 
syntax errors in one pass (most current batch 
processing compilers could be much better 
designed from this point of view), and (2) 
that fewer results will be printed since the 
person with the problem knows he can easily 
get other results if needed. I am willing to 
admit that there will be a reduction in the 
printing of wrong results, but at reasonable 
traffic levels the person with a problem to be 
solved does not easily get other results. Con- 
sequently, when he thinks his program is cor- 
rect (and he is an eternal optimist) he will 
ask (curbed only by hard cash economics) for 
extensive print-outs at the central computer 
facilities. 

It is unfortunate that the problems of satu- 
ration of the on-line console system were not 
discussed. 

Whatever the true picture relative to the 
costs of batch processing versus console com- 
puting, there is no doubt whatsoever that from 
the point of view of elapsed time the console is 
far superior. As Weizenbaum says: Man is 
conserved, not the machine. 



On the other hand, the system designer has 
a tremendous task in discouraging the user 
from experimenting trivially just to see what 
wonderful things will be done for him. 

It is exactly this last point and the eco- 
nomics discussed above that leads us at 
Berkeley not to plan for consoles for under- 
graduate teaching purposes. In fact, these 
students do not even get normal turn around. 
If their problems are left by a fixed time in 
the evening the results will be back the next 
morning. This system permits the assignment 
of a substantial problem once a week due one 
week later. 

At the same time we are installing remote 
consoles (1050's) which, during scheduled 
periods provides QUIKTRAN, and at all other 
times permits communication with problems 
in process in the DCS system (problems run- 
ning under IBSYS, FORTRAN II monitor, 
and numerous special languages such as 
COBOL, COMIT, SNOBOL, IPL, NELIAC, 
etc.). Such facilities will be available to gradu- 
ate students and staff but not in undergradu- 
ate teaching. 

FUTURE OF ON-LINE COMPUTING 
Walter Bauer has estimated that by 1975, 
90 percent of computing will be done ON- 
LINE. I would like to examine this for a 
moment. Following Ivan Sutherland we can 
divide computing into the following cate- 
gories : 

1. Process control 

2. Inquiry Stations 

3. Process control 

Specialized Systems (Engineering 
Design) 

4. Instrumentation of on-line systems 

5. Programming Systems 

6. Problem Solving Systems 

Categories one through four are intrinsically 
on-line. The tasks associated with five and six 
can be accomplished by batch processing or 
on-line techniques. My opinion is that (because 
of economics and, in line with the discussion 
of the preceding section) program debugging 
and problem solving will always be done both 
on-line and by batch processing. In these two 
areas the balance is anyone's guess— it depends 
strongly upon the relative accomplishments in 
the improvement of batch processing tech- 
niques and in the improvement of on-line tech- 
niques. My guess is that the division will be 
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about 50% -50%. It is possible that in 1975 
process control, inquiry stations, and on-line 
instrumentation will represent 80 percent of 
the total computing done, in which case Walter 
Bauer's estimate would be right. However, I 
believe that more than 10 percent of the total 
computing will still be batch processing. 

INSTRUMENTATION 
The evidence of the lack of precise informa- 
tion in the two preceeding sections supports 
the contention of Sutherland and Amdahl that 
much more instrumentation of on-line systems 
is needed so that we know what is going on, 
what the typical user does, and what the vari- 
ations are from the norms. It is only with this 
information that systems can be "trimmed" 
so as to optimize usefulness to the customer 
array. 

TYPES OF COMPUTER USERS 
Computer users can be classified into two 
groups : Those who require hardware response 
before loss of attention occurs or frustration 
cancels any advantage, and those who only 
need results some time later (minutes, hours, 
or days) as they can, without ultimate loss, 
turn their attention to other tasks in the inter- 
vening period. The on-line user is thus dis- 
tinguished from the batch processing user. 

It is also possible to classify users on an- 
other scale as follows : 

1 . The query user, who asks the machine 
(hardware and software) questions and 
expects answers in real-time (he awaits 
the answer without transferring atten- 
tion to other matters) . 

2. The reaction user, who submits himself 
to the control of the machine. Usually 
the decisions involved depend upon an 
environment too complex and too quickly 
changing for a man (or team of men) to 
make the decisions. The answers to all 
questions are programmed a priori. An 
example is the abortion program of pro- 
ject Mercury. 

3. The heuristic user. A complex problem 
is under consideration, and the complete 
exploration of the solution tree is beyond 
the capability of the system (probably 
time- wise) . Therefore, on some basis the 
solution tree is pruned by the man and 
the machine moves him through the re- 
duced tree. 



4. The partnership. The partnership be- 
tween man and the machine can range 
from a limited partnership as repre- 
sented by Morrissey's QUIKTRAN to a 
more general partnership represented by 
project MAC at MIT, or the time sharing 
system at SDC. The work on self-organ- 
izing systems is looking forward to even 
more interesting partnerships. 

FAIL SAFE 
On-line systems are still in their early de- 
velopment stage, but now that systems are 
beginning to work, I think that it is obvious 
that more attention should be paid to the fail 
safe aspects of the problem. Topics to be con- 
sidered here are memory protection or assign- 
ment, system controlled input and output, and 
well designed user language features. The 
merits of simpler systems, like JOSS, should 
not be discounted. Walter Bauer made a sig- 
nificant point in this respect : the user should 
be led down a procedural path. 

THE CULLER-FRIED APPROACH 

The use of a storage tube simplifies the 
remote station device, placing it in the same 
cost area as sophisticated teletype-style sta- 
tions. Although such stations are not as ver- 
satile as the dynamic or memory buffered 
types, they nonetheless accomplish the most 
significant improvements in communication 
that display scopes represent. In fact, the 
comments of Pope and Tomkins support the 
old adage : a picture is better than a thousand 
words. 

As indicated by Pope, perhaps the most im- 
portant aspect of such station systems is their 
aid in the development of the solution algor- 
ithm. In comparison, teletypewriter methods 
might be like trying to appreciate the art in 
the National Gallery by exploring it at night 
with a pencil size flashlight. 

ENGINEERING DESIGN 
WITH DISPLAYS 
The use of display consoles in engineering 
design seems to me (an outsider) to be push- 
ing the state of the art a bit. My feeling is 
that here is a powerful technique with almost 
unlimited potentialities and, therefore, I 
strongly support all the work in the field. 
However, at this early stage in the develop- 
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ment I feel that at best it is a clumsy tool. 
Therefore, we should be extremely careful 
about raising false hopes. 

On the other hand, the very complete pre- 
sentation of Donn Parker shows a tremendous 
effort in this direction. And whatever the 
relative efficiencies of this tool, I "drool" when 
thinking about the possibility of using the 
system. In fact, I wonder about incentives 
to minimize the "playing around" of the 
operator? 

LANGUAGES 

As illustrated in the MAC system and in 
Donn Parker's system, we are going to see 
many problem oriented language systems for 
use with remote stations. So far, many of these 
are adaptations of batch processing languages, 
but time will see the development of systems 
optimized for remote-on-line use. 

In the area of procedure oriented languages 
QUIKTRAN is an adaptation of the batch 
processing language FORTRAN. In review- 
ing Johnson's PAT language one wonders if 
it could not have been developed with a much 



closer relationship to either ALGOL or NPL. 
For language exploration this is not too im- 
portant. However, if anyone is developing a 
language which he expects to be widely used, 
then he should base it on either ALGOL or 
NPL if possible. 

SUMMARY 
I am impressed by the large show of interest 
in the subject, and I hope this is symptomatic 
of a hard look at the problems of improving 
batch processing systems and, more impor- 
tantly, at the greater variety of tools available 
by improved man-machine interface equip- 
ment (hardware and software). I feel that 
the culmination of the developments described 
in this set of papers marks the first real step 
in improving the use of the computer as a 
research and development tool. In other words, 
making the computer available to an indivi- 
dual on a more or less continuous basis is the 
first significant step in improved use of com- 
puting equipment since the first automatic 
computer was put into operation in 1949. 
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